J
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
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
)