Re: Distributing and updating application for market
- From: Malcolm P <MalcolmP@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 23 Dec 2005 04:08:02 -0800
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" wrote:
> 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
>
>
.
- Follow-Ups:
- References:
- Prev by Date: Re: Checking for value in a table
- Next by Date: Re: built in fields of Outlook
- Previous by thread: Re: Distributing and updating application for market
- Next by thread: Re: Distributing and updating application for market
- Index(es):
Relevant Pages
|
Loading
