Selling Access app to general public?

[brooks]

I have an Access 97 app and the ADT and am considering selling it to
the public.

Is this viable? What issues might I have?

I also have Access 2000 and could use that if it would be better. I
don't have the "ADT" for 2000. Is it called ODE or ODT? Can you still
buy that?

Would there be any advantage in moving up to and distributing using
Access 2002 or 2003?

I'm not up on .NET technology.

Appreciate any advice.

Brooks

[Rick Brandt]

br****@rimesrv.net wrote:

I have an Access 97 app and the ADT and am considering selling it to
the public.

Is this viable? What issues might I have?

I also have Access 2000 and could use that if it would be better. I
don't have the "ADT" for 2000. Is it called ODE or ODT? Can you
still buy that?

Would there be any advantage in moving up to and distributing using
Access 2002 or 2003?

I'm not up on .NET technology.

Appreciate any advice.

As long as you don't require any of the features in the newer versions Access 97
will provide an app that is smaller, faster and which will run on more PCs.
Since there is no reason to use more than one runtime then that is what I would
use.

Most of the "issues" with the runtime involve installing it on PCs where a
version of Access already exists. This should be avoided whenever possible.
The ultimate installation package for your app would be one that installs only
the application and support files of the proper version on PCs that already have
Access installed and which includes the runtime only on PCs that don't have any
version of Access already installed. This sounds daunting, but since Access
2002 and 2003 can both run Access 2000 files just fine you really only need two
file versions, one in Access 97 and one in Access 2000. This means you have
three scenarios that you can cover pretty easily...

* Target PC has no version of Access
(install 97 runtime and all support files)

* Target PC has Access 97
(install Access 97 file and all support files)

* Target PC has Access 2000 or higher
(install Access 2000 file and all support files)

The ADT for Access 97 cannot build such an intelligent installer, but it can be
configured to install as many MDBs in as many versions as you want to include as
well as the 97 runtime and all of these can be configured as optional
components. This would at least allow a user that is knowledgable about his
system to only install the components that are appropriate for his situation.

If you obtain more complex installer packages like Wise, InstallShield, etc.,
then it might be possible to build an installer that requires less of the person
running the install, but you would need to investigate that to see what the
exact capabilities of those programs are.

Another way to go is to build a runtime install package that uses the scripts
that can be purchased from Sagekey. These scripts make the runtime installation
of your app so that they are much more independent. By that I mean that they
don't "mess with" any other versions of Access that might or might not exist on
the target PC. I have never used these, but everything I have ever read about
them indicates that they work as advertised.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[TC]

Further to Rick's comments:

There is an enormous difference between an app that you can use
yourself, or give to colleagues in the same area, and an app that you
provide on CD to people all over the place.

1. The app must be absolutely as bug-free as you can possibly make it.
Small errors that you automatically work-around youself, when you &
your colleagues use the app, can easily cause untold grief, when other
people (in other locations) start to use it.

2. The app must be properly documented. This might mean online (F1)
help for every screen & report; a detailed, printed (or printable) User
Manual; and maybe even some "quick start guides" for critical
functions.

3. You have to have a bulletprooof installer process. The users will
hate you if your install process damages their retail copy of Access!
For that reason, I say to people who buy my products: "You must have a
working, retail copy of Access version x, y or z on your PC". It is up
to them, to get that. Despite this, I still have an installation
program of several hundred lines, written in a commerial installation
product, which checks the user's version of Access, installs the proper
files for that version, and so on.

4. You may need to design a registration process to discourage people
from copying your software. There are lots of ways to do this, some of
them better than others.

5. You need a mechanism (website or whatever) for people to report bugs
etc.

IMHO, those requirements can easily be as much as, or even more than,
the effort required to build the app in the first place! So it can be
difficult to take the average "in house" Access app, and turn it into a
commercial product, without a substantial amount of extra work.

HTH,
TC

[Tom van Stiphout]

On 4 Dec 2005 20:29:50 -0800, "TC" <aa**********@yahoo.com> wrote:

All good points, and one more:
* You need a procedure to respond to support requests.
All of a sudden you'll find yourself in the support business. People
will ask you a very wide range of questions, will accuse your (setup)
program from generating a very wide range of problems, etc.

-Tom.

Further to Rick's comments:

There is an enormous difference between an app that you can use
yourself, or give to colleagues in the same area, and an app that you
provide on CD to people all over the place.

1. The app must be absolutely as bug-free as you can possibly make it.
Small errors that you automatically work-around youself, when you &
your colleagues use the app, can easily cause untold grief, when other
people (in other locations) start to use it.

2. The app must be properly documented. This might mean online (F1)
help for every screen & report; a detailed, printed (or printable) User
Manual; and maybe even some "quick start guides" for critical
functions.

3. You have to have a bulletprooof installer process. The users will
hate you if your install process damages their retail copy of Access!
For that reason, I say to people who buy my products: "You must have a
working, retail copy of Access version x, y or z on your PC". It is up
to them, to get that. Despite this, I still have an installation
program of several hundred lines, written in a commerial installation
product, which checks the user's version of Access, installs the proper
files for that version, and so on.

4. You may need to design a registration process to discourage people
from copying your software. There are lots of ways to do this, some of
them better than others.

5. You need a mechanism (website or whatever) for people to report bugs
etc.

IMHO, those requirements can easily be as much as, or even more than,
the effort required to build the app in the first place! So it can be
difficult to take the average "in house" Access app, and turn it into a
commercial product, without a substantial amount of extra work.

HTH,
TC

[TC]

I established a website with an online forum where people could go to
ask questions etc. Unfortunately, after a whole year trying, I've
failed to get them to go there, at all.

Now I'm considering adding a "Send Feedback!" button to every screen &
report. I'm making it a hyperlink, not a button, so it looks a bit more
"web like". When they click that link, they'll get a textbox in which
to type comments. Then, when they hit [Send], their comment (and extra
information) will be emailed to me behind the scenes, using an SMTP
engine written in VBA - so there is no reliance on their PC's email
software, if any.

I got this feedback idea from what Micosoftsoft do in certain beta
software. It remains to be seen if my users will go for it. If they
won't even click a link & type a comment, I can' see what more I could
do for them.

Cheers,
TC