Distributing Access Applications

[John Phelan]

I read an article by, by Mike Groh, in Access-VB-SQL Advisor Magazine,
Week 37 that concerns me quite a bit on distributing Access
Applications commercially.
First I need to describe a "commercial version" of my application that
I hope to distribute after completing all the beta testing:

A. It was developed using MS AccessXP Pro (developers edition),

B. It has a front end MyApplication.mdb and a MyAppBbackend_be.mde;
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,

C. I include the Access Runtime in my packages (and use the, "\runtime
switch") in order that my application does not interfere with previous
and existing versions of Access that may already exist on end-user
machines (and vise versa,

D. On my report forms I include buttons for Word and Excel in case
people want to dumb reports into either of those programs. I do not
have any Access library references checked for either of those
programs,

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.

F. Determining what computer configurations my application will run
on; I have so for narrowed my software requirements to:

a. Operating Systems: Windows 98SE, Windows2000+, and XP with
"MDAC_TYP
version 2.8 (minus MS recommended "Server exclusions (does not include
‘98 and ‘ME). In another year or two, I'll probably delete Win98SE
and 2000 as I continue to upgrade my developers' version of Access.

b. Computers: Pentium III with 64mg minimum, 124 min, recommended,
plus 8 meg per Office program. I am determining what configurations
my software will support during testing in order to minimize ongoing
support for the many computer configurations that are out there.

Now, I read this article by Mike Groh, who, in part, states, "The bad
news is Access applications are notoriously difficult to distribute to
large numbers of users. In fact, I know of no commercially available
application written in Access, although there are a few that use the
..MDB file format for their data. "

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.

B. Also, differences as small as having a different Office service
pack installed are enough to cause an application to stop working or
refuse to install properly i.e., installing an Access 2000 runtime
application causing AOL to stop working.

C. Other Office products (like Excel, Word, or Outlook), this adds a
level or two of complication, as the necessary libraries may not be
there (or not properly referenced).

D. Installing on the various computer configurations there is the
issue of ongoing support as access applications can be notoriously
support hungry.

At one point, he states, "Your best bet in getting an Access
application distributed is to invest in a professional installation
tool such as Wise (http://www.wise.com) or InstallShield
(http://www.installshield.com), then get the SageKey installation
scripts (http://www.sagekey.com) to build your distribution package.
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."

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."
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, and
have incurred all sorts of other developer cost that goes with
it,(help authoring programs, custom codes, etc, etc.), that I am
certain everyone reading this can appreciate.

Now it is being suggested that I'll have to, ". . . invest about
still another US$1,000 in installation software." The
"InstallShield" software alone cost approximately, $1,200.00 bucks.

Is this for real; is the cost of this additional investment that is
being suggested really necessary?

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?

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?

John

[Albert D. Kallal]

> B. It has a front end MyApplication.mdb and a MyAppBbackend_be.mde;

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,
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.

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.
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?
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."
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.

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."
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.

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
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.
Now it is being suggested that I'll have to, ". . . invest about
still another US$1,000 in installation software." The
"InstallShield" software alone cost approximately, $1,200.00 bucks.
$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.

Is this for real; is the cost of this additional investment that is
being suggested really necessary?
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!).
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?
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!

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?

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
ka****@msn.com
http://www.attcanada.net/~kallal.msn

[John Phelan Cummings]

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]

jp*********@earthlink.net (John Phelan Cummings) wrote in
<3f***********************@news.frii.net>:

backend_be.mde
backend_be.mde

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]

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

<snip>

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?

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!

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/prev.../accessdav.asp
Steven R. Zuch
Cogent Management Inc.

[Tony Toews]

jp*********@earthlink.net (John Phelan) wrote:

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.

Tools available from sites such as sysinternals.com 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
http://www.granite.ab.ca/accsmstr.htm

[TC]

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:ll********************************@4ax.com...

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

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]

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" <la**********@ntpcug.org> wrote in message
news:kN*****************@nwrddc02.gnilink.net...

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 on 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...

"Tony Toews" <tt****@telusplanet.net> wrote in message
news:ll********************************@4ax.com...

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

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]

Chuck Grimsby <c.*******@worldnet.att.net.invalid> wrote in message
news:hr********************************@4ax.com...

(snip)

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.
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_Parts permission
a standard off-the-shelf $995 FPGA evaluation board from Altera
about two days of "cracking" time 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.

[TC]

Chuck Grimsby <c.*******@worldnet.att.net.invalid> wrote in message
news:hr********************************@4ax.com...

(snip)

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.
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_Parts permission,
o a standard off-the-shelf <$1000 FPGA evaluation board, and
o about two days of elapsed "cracking" time.
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.

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]

<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.