Distributing and updating application for market

[Guest]

I have developed an application which I would like to market.

I invested in Access 2003 and Visual Studio Tools for Office 2003 (which
includes the Access 2003 Developer Extensions) in order to allow me to
create a distribution disk. I found that the runtime verison is useless:
no AutoCorrect or Filter by Form, two items critical to the use of the
application. Consequently, I can market the application only to those who
invest in Access. I used the software from the above to create a disk which
installs the program on the purchasers computer.

My question now is what do I have to do to distribute updates to the
purchaser?

I am not a programmer !! I was able to develope the application without
the use of much code: only a few pages of code; very simple. The wizard
that came with the VST and ADE allowed me to point and click my way through
creating the distribution disk. Is there software available which
simplifies the updating process to a point and click operation????????? For
example: allowing me to specify the form or report, etc. to copy over on the
original distributed version on the purchaser's computer with the new form or
report, or allowing me to add a field to a table without impacting the
table's data???????? Or is this task too impossible for a non-programmer and
hiring someone to help the only alternative?????????

Any help or direction would be sincerely appreciated.

 

[TC]

If you are not a programmer, you will find it very, very difficult to
build a commercial grade product, IMHO.

First, there may be lots of folk out there with Access 97, 2000, or
2003. Your Access 2003 database will not work for any of them. Your
installation program (whatever it is) should check the PC's version of
Access, & give them a suitable warning, so they don't install your
product & then find it does not work. Alternatively, you should
distribute an Access 97 version for those folk with Access 97, and an
Access 2000 version for those folk with Access 2000, 2002 or 2003. And
all those files should be MDE files - not MDB files. Look up MDE in F1
help.

Second, your db should be split into a so-called "front end/back end"
(FE/BE) structure. If you have not done that yet, you will /not/ be
able to distribute /any/ updates. Google those terms for more
information.

Third, things like "query by form" can be programmed-up explicitly, so
you can use them even in a runtime app.

Here are five MORE things that I said to someone recetly with a similar
question!

<quote>

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.

</quote>

HTH,
TC

 

[Guest]

Thanks for the response.
Can you provide me with an outline of the steps to complete IMHO?
Is there software I have to acquire and use that will be sufficient to
complete the project of the original distribution disk and the update
function?
Is software available similiar to Access that allows programming without the
use of code?

 

[TC]

Can you provide me with an outline of the steps to complete IMHO?

Not really. I can only list some of the outcomes that you need to
achieve - and I have already done that. For example, I said that you
need to split your database into a so-called front-end/back-end
structure. The ball is really in your court, to research those terms &
see what they mean, & how to achieve that.

Is there software I have to acquire and use that will be sufficient to
complete the project of the original distribution disk and the update
function?

I can only answer for what I've done myslf, to distribute my own Access
product. I purchased an installation program called Setup Factory (at a
cost of $1,000); spent quite a few weeks learning how to program that
product (it's fairly tricky); then wrote about 500 lines of code (in
that product) to control the installation process. Your milage may
vary!

Is software available similiar to Access that allows programming without the use of code?

That depends on what you mean by "software", "programming", and "code".
With the meanings that I give to those terms, your question translates
to the following: "Is a programmning environment available that allows
programming without the use of program code?" My guess is - not likely!

Malcolm, I'm not trying to be rude or dismissive. But if you plan on
distributing a commercial product, you might as well get the hard news
here: it's not easy, it requires a singnificant degree of technical
competence, and you run the risk of getting your fingers /well & truly
burned/ if you do not do it correctly.

Why not try packaging-up your product & giving it to a frind to
install. If that goes well - so be it! If it doesn;t, you can find out
hat went wrong, improve the process, & try again. That would be a
low-risk way to see if you can build a product that will surivive in
the cold, hard outside world!

HTH,
TC

 

[Guest]

Thanks again TC.

Apparently I'll have to learn to write code. What programing language are
we talking about (re. your 500 lines of code)?

 

[TC]

PS. IMHO = "in my humble opinion"

TC

 

[Guest]

What programing language are we talking about (re. your 500 lines of code)?
Is it VBA, Visual Basic for Applcations?

 

[Guest]

Hi Malcolm,
I learned a little VB.net and it works well in Access. Also knowledge of SQL
will do well. Good luck.
Karl