Distributing Access Applications

**Albert D. Kallal** · Nov 12 '05, 02:18 PM

Re: Distributing Access Applications

> B. It has a front end MyApplication.m db and a MyAppBbackend_b e.mde;[color=blue]
> the front end is not an "mde" so that I am able to provide patches and
> updates to it. I have code include that automatically seeks out the
> back end whenever patches and updates are provided,[/color]

Gee, I would use a mde, and just simply supply a new mde for each update.
There is a LOT OF risk disturbing a mdb front end. Are you going to pay for
support problems as results of users modifying the application? (no to
mention the exposure of your code etc.). I would REALLY think long and hard
about this.
[color=blue]
>
> Some of the difficulties he sites in this article include: (edit for
> space)
>
> A. The many different versions and formats of Office that exist.
> Installing an application built in Access 2000 might, for instance,
> break Access 97 applications already residing on the user's computer.
> Access has a significant impact on registry settings.[/color]

Of course, any developer who is actually developing office appcltions knows
that mixing and matching office appcltions can cause problems. This should
come as no surprise. If you are so far as to start disturbing an
application, surly you must have come across the concept that mixing
versions of ms-access on a pc is full of danger? Remember, the runtime is no
different in this regards, and I am not sure why you would think so?
[color=blue]
> All in all, you'll invest about US$1,000 in installation software, and
> have to master creating distribution packages before you'll be able to
> confidently send out software to install."[/color]

Setting up the software install of your application is going to be
sizeable portion of your software budget. Microsoft had 80 full time people
on JUST tin their installer for Excel at one time. Welcome to the world of
software development! You can't scrimp on setting up the install.
Obviously this is new territory for you.
[color=blue]
>
> Finally he suggests that, "If you haven't already looked at it the
> VB.Net development environment is pretty cool and runs well on most
> modern win operating systems."[/color]

The above suggestion is simply suggesting that for wide distribution, you
might want to avoid using ms-office (access) and consider writing the
application in VB.net, or something designed with larger distribution in
mind.
[color=blue]
>
> My Concerns:
>
> 1. I have invested lots of bucks in purchasing MS Office Developer
> Editions and all the upgrades in between over the past 5 years[/color]

Ah, ok, then you are not new to the problems of installing and setting up
ms-access on a mixed platforms. For a second, I thought you might be new to
development.
[color=blue]
> Now it is being suggested that I'll have to, ". . . invest about
> still another US$1,000 in installation software." The
> "InstallShi eld" software alone cost approximately, $1,200.00 bucks.[/color]

$1,200 is not much these days. Heck the developer edition of office is $800
(very cheap). The professional developer edition of vb used to be a lot more
then the above two combined.

However, companies like sagkey make scripts for Wise, InstlalSheild, or MSI.
Msi is the Microsoft installer (purchase from wise). You can use the MSI
installer included with the developer edition of office.

However, developing your own scripts can take a lot of time. You can
purchase
scripts from sagkey for the MSI. Purchasing the scripts from sage key sounds
like really good idea, and is only $425. If you can develop a good install
script in less then two days of programmer time, then I guess $425 sounds
expensive. To me, that is bargain, and for $425 of my time, I can't come
even close creating my own scripts.
[color=blue]
>
> Is this for real; is the cost of this additional investment that is
> being suggested really necessary?[/color]

No, you don't have to purchase all the of experience and problems and
learning that the folks at sagkey went through. You can spend the time (many
months) of learning what does, and what does not work (and, your customers
will not be too happy either as you learn on their frustration!).
[color=blue]
> 2. Is VB.Net intended to replace AccessXP Developers Edition? Dumb
> question time; what does MS Access Developers Edition have to do with
> VB.Net; what impact do they have on each other?[/color]

As mentioned, the author of those comments is suggesting that since
ms-access is
tied to a particular version of office (with all of the problems), then you
might want to consider developing with something else other then office.
However, the developer edition of office is being changed to a development
kit that will ship with Visual Studio. This is likely a VERY GOOD thing!
[color=blue]
>
> 3. When I include the Access Runtime in my packages (and force use
> the, "\runtime switch") switch") and if I am not making ANY references
> to Outlook, MS Word, or Excel, etc. in my Access library, shouldn't
> that address any issue regarding what is properly referenced or What
> gets add to the registry?[/color]

It certainly helps, but has no bearing on the problems that exist when you
mix and match parts of ms-office.

If you are telling me that you wish the install and setup tools for Office
developer were better, then you are not alone. If you are telling me that
you think the tools should also be better in this regards, then again I 100%
with you. However, the fact that mixing office applications does remain.
There is SO MANY parts to the office system, and thus it is quite a lot to
expect to turn ONE part of office into some stand alone application that
does effect the rest of the pc.

However, there is signs that the a2003 office developer will have much
better install scripts included since it is being moved to Visual Studio. I
am keeping my fingers crossed!

--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
kallal@msn.com

http://www.attcanada.net/~kallal.msn

**John Phelan Cummings** · Nov 12 '05, 02:18 PM

Re: Distributing Access Applications

I have code in the frontend.mdb that automatically relinks to the
backend_be.mde when I provide updates and patches.
My rational for doing things this way is:

a). I was told that I should not let people have access to hou the
tables were constructed and their relationships.

b). The code that I use in the frontend.mdb for providing updates, ONLY
work in frontend.mdb files, that you cannot use it with .mde
frontend.mde files. However, frontend.mdb files will link to
backend_be.mde files.

Also, I have inserted the "AllowByPassKey " code in a .dll instead of a
module, changed the password to my database, made certain that the
Access Window was not visible,etc., on the frontend for security.

John

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

**David W. Fenton** · Nov 12 '05, 02:20 PM

Re: Distributing Access Applications

jphelan2000@ear thlink.net (John Phelan Cummings) wrote in
<3f616f76$0$620 81$75868355@new s.frii.net>:
[color=blue]
>backend_be.m de
>backend_be.m de[/color]

You do know that a back end is supposed to be only data tables, or
it's not really a back end? And, therefore saving it as an MDE
accomplishes nothing, since the only difference between an MDB and
an MDE is in code?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

**Steve** · Nov 12 '05, 02:20 PM

Re: Distributing Access Applications

On Fri, 12 Sep 2003 00:44:55 GMT, "Albert D. Kallal" <kallal@msn.com >
wrote:

<snip>
[color=blue][color=green]
>> 2. Is VB.Net intended to replace AccessXP Developers Edition? Dumb
>> question time; what does MS Access Developers Edition have to do with
>> VB.Net; what impact do they have on each other?[/color]
>
>As mentioned, the author of those comments is suggesting that since
>ms-access is
>tied to a particular version of office (with all of the problems), then you
>might want to consider developing with something else other then office.
>However, the developer edition of office is being changed to a development
>kit that will ship with Visual Studio. This is likely a VERY GOOD thing!
>[/color]

The Access Developers Edition is now Access 2003 Developer Extensions.
Included is new deployment tools that appear to address the multiple
versions of Access on the target PC problems.

The Access 2003 Developer Extension is part of the new Visual Studio
Tools for the Microsoft Office System, which is different thant Visual
Studio.Net. However Visual Studio Tools does include Visual
Basic.NET.

The fact that VB.NET is being included with the Access Developers
sofrware is very interesting.

See:

http://www.microsoft.com/office/preview/editions/accessdav.asp

Steven R. Zuch
Cogent Management Inc.

**Tony Toews** · Nov 12 '05, 02:21 PM

Re: Distributing Access Applications

jphelan2000@ear thlink.net (John Phelan) wrote:
[color=blue]
>E. I will have code for a, "a-number-of-days" expiration that will
>also prevent calendar "rollbacks" , plus the ability to extend
>demo/beta calendar periods; "amenities that I feel should be included
>in MS Access Developers Edition. But, that's another post I guest.[/color]

Tools available from sites such as sysinternals.co m can crack any method you use to
store a future date anywhere on a system such as in the registry or a file.

Thus I prefer to limit the number of records in one key table such as 5 units or 50
volunteers but allow unlimited access for everything else. Once I get paid then I
email them an encrypted file containing the number of records they are licensed for
as well as their company name which goes on the bottom of every page of every report.

For more of my thoughts on this topic see my "Copy protection or how to safely
distribute a demo Microsoft Access Application" page at my website.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at

Tony's Main Microsoft Access Page

http://www.granite.ab.ca/accsmstr.htm

Tony's Microsoft Access Hint's, Tips and FAQ

TC · Nov 12 '05, 02:21 PM

Re: Distributing Access Applications

"Tony Toews" <ttoews@teluspl anet.net> wrote in message
news:ll17mvsaoh 7435c7nj823rurv vcmem1eml@4ax.c om...

[color=blue]
> Tools available from sites such as sysinternals.co m can crack any
> method you use to store a future date anywhere on a system such
> as in the registry or a file.[/color]

Here we go again! Why do you keep saying this? As I have said before, values
can be encrypted & checksummed to stop the user making any sense of them, or
changing them, or even resetting them to previous values.

Think about it! Take the data that is transmitted from one bank to another,
to effect a transaction. Is that data secure because it is hidden away out
of sight, where no-one can see it? Would it become *insecure* if someone
could tap the lines, & print it out? No. You could publish the whole data
packet on the front page of the daily news, & it would *still* be secure,
because it has been encryted & checksummed.

I don't like to keep harping on about this, & I am not trying to have a go
at you - but you do keep repeating this misinformation :-)

TC

TC · Nov 12 '05, 02:22 PM

Re: Distributing Access Applications

I entirely agree that any PC based scheme can be cracked by modding the
code. But that's not the point at issue. TT says that you can't store
registration data in the registry, because this can be found using tools
from wherever. (Then, it is implied, the user could change it to affect the
registration.) I disagree with this. You *can* store registration data in
the registry, as long as it is encrypted & checksummed. Then, the cracker
can *not* change that data, & get away with it. He may well be able to break
your scheme by modding the code, but he *won't* be able to do it by changing
the data you store in the registry.

TC

"Larry Linson" <larry.linson@n tpcug.org> wrote in message
news:kNa9b.9813 $1D5.4739@nwrdd c02.gnilink.net ...[color=blue]
> A good hacker/cracker can break the code, or can just find where the
> information is being stored or checked and bypass that check. Encryption
> isn't failproof.
>
> You can go to the warez sites and get cracks that bypass ownershp checks[/color]
on[color=blue]
> most any heavy-duty security commercial software. It pays, however, to be
> very cautious if one does this, even if you don't get caught for copyright
> violation. Fake cracks are a vehicle of choice for virus authors, and a
> virus that is only far enough along to be piggybacking on a fake crack may
> not yet be in the AV list.
>
> Larry Linson
>
> "TC" <a@b.c.d> wrote in message news:1063520736 .498942@teuthos ...[color=green]
> >
> > "Tony Toews" <ttoews@teluspl anet.net> wrote in message
> > news:ll17mvsaoh 7435c7nj823rurv vcmem1eml@4ax.c om...
> >
> >[color=darkred]
> > > Tools available from sites such as sysinternals.co m can crack any
> > > method you use to store a future date anywhere on a system such
> > > as in the registry or a file.[/color]
> >
> >
> > Here we go again! Why do you keep saying this? As I have said before,[/color]
> values[color=green]
> > can be encrypted & checksummed to stop the user making any sense of[/color][/color]
them,[color=blue]
> or[color=green]
> > changing them, or even resetting them to previous values.
> >
> > Think about it! Take the data that is transmitted from one bank to[/color]
> another,[color=green]
> > to effect a transaction. Is that data secure because it is hidden away[/color][/color]
out[color=blue][color=green]
> > of sight, where no-one can see it? Would it become *insecure* if someone
> > could tap the lines, & print it out? No. You could publish the whole[/color][/color]
data[color=blue][color=green]
> > packet on the front page of the daily news, & it would *still* be[/color][/color]
secure,[color=blue][color=green]
> > because it has been encryted & checksummed.
> >
> > I don't like to keep harping on about this, & I am not trying to have a[/color][/color]
go[color=blue][color=green]
> > at you - but you do keep repeating this misinformation :-)
> >
> > TC
> >
> >
> >[/color]
>
>[/color]

TC · Nov 12 '05, 02:24 PM

Re: Distributing Access Applications

Chuck Grimsby <c.grimsby@worl dnet.att.net.in valid> wrote in message
news:hrkcmvsvdh frof0adpma524k6 fs9imu32a@4ax.c om...

(snip)
[color=blue]
> Most financial institutions use a two-person method to help ensure that
> this level isn't broken, but not all do that. And there have been
> cases where even that methodology of security has been bypassed by
> willing (or unquestioning) co-workers.[/color]

Extracting a 3DES key from an IBM 4758
Summary
The IBM 4758 is an extremely secure cryptographic co-processor. It is used
by banking systems and in other security conscious applications to hold
keying material. It is designed to make it impossible to extract this keying
material unless you have the correct permissions and can involve others in a
conspiracy.

We are able, by a mixture of sleight-of-hand and raw processing power, to
persuade an IBM 4758 running IBM's ATM (cash machine) support software
called the "Common Cryptographic Architecture" (CCA) to export any and all
of this program's DES and 3DES keys to us. All we need is:

about 20 minutes uninterrupted access to the device
one person's ability to use the Combine_Key_Par ts permission
a standard off-the-shelf $995 FPGA evaluation board from Altera
about two days of "cracking" time[color=blue]
> In the end, there *is* no such thing as a 'perfect' system. Period.
> Anyone who believes otherwise hasn't thought things through, or is
> making assumptions on conditions which may not be as accurate as they
> think.
>
>
> --
> Your Boss Is Thinking About You.
>[/color]

TC · Nov 12 '05, 02:24 PM

Re: Distributing Access Applications

Chuck Grimsby <c.grimsby@worl dnet.att.net.in valid> wrote in message
news:hrkcmvsvdh frof0adpma524k6 fs9imu32a@4ax.c om...

(snip)
[color=blue]
> Most financial institutions use a two-person method to help ensure
> that this level isn't broken, but not all do that. And there have been
> cases where even that methodology of security has been bypassed by
> willing (or unquestioning) co-workers.[/color]

Amazingly, the 2-person method has been broken! Researchers have found out
(and published!) how to extract the 3DES keys from an IBM 4758
crytoprocessor running CCA, with nothing more than:
o 20 minutes uninterrupted access to the device,
o one person's ability to use the Combine_Key_Par ts permission,
o a standard off-the-shelf <$1000 FPGA evaluation board, and
o about two days of elapsed "cracking" time.
[color=blue]
> In the end, there *is* no such thing as a 'perfect' system. Period.
> Anyone who believes otherwise hasn't thought things through, or is
> making assumptions on conditions which may not be as accurate as they
> think.[/color]

No argument there!

TC

PS. please ignore my other reply where I inadvertantly sent some pasted text
without any editing. I have cancelled that post, but knowing usenet, it will
still show up anyway :-(

**Dr Doogie** · Nov 12 '05, 02:25 PM

Re: Distributing Access Applications

<snip>

As a long term user of Sagekey I can also verify its ability to allow
the installation of Access products onto PC's with varying OS/Office
combinations.

What I can't imagine happening is a lot of smaller developers paying a
fortune to deploy Access 2003 packages:

1 * Office 2003
1 * Microsoft Visual Studio Tools for Office 2003
1 * Sagekey Script for Office 2003 (when it's released)

It it too much to ask for Microsoft to get the package and deployment
wizard to finally work correctly???

For christ sake the Access XP P&D wizard wouldn't work on Windows
98/Me/NT out of the box….which for a number of businesses is still the
main operating system of choice.

The Doctor.

Distributing Access Applications

Distributing Access Applications

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment