AccessAppStarter

[Todd Matson]

A couple of years ago, I wrote a program I call the AccessAppStarter to help
me deploy Access applications. Since then, it has become indispensable to
me. I've used it with every Access application I've written. I was
reflecting on this today when it occurred to me that other developers might
find it useful too, so I've posted it at
http://MatsonConsulting.com/download...appstarter.zip for everyone to
use. If someone can tell me how to release software with an open source
license, I'll post the source code too.

What the program does is very simple. Instead of running MSAccess.exe with
the front-end file as a command line parameter, you instead run
AccessAppStarter.exe with the front-end file as a command line parameter.
AccessAppStarter will then run MSAccess.exe, but before it does it will
perform a few useful functions:
1) It will check the registry to see if it knows the location of the
workgroup file. If it doesn't, it will prompt the user for the location and
save it to the registry. Then, when it runs MSAccess.exe, it will use the
workgroup file. Every front-end file can have a different workgroup file
associated with it.
2) It will check the registry to see if it knows the location of the
back-end data file. If it doesn't, it will prompt the user for the location
and save it to the registry. Then, when it runs MSAccess.exe, it will pass
the location as a command line parameter. Every front-end file can have a
different back-end file associated with it.
3) It will check the registry to see if it knows the location of the
resource folder. (The resource folder is a place on the network where the
front-end will look for expected files, or where it can write shared data.)
If it doesn't, it will prompt the user for the location and save it to the
registry. Then, when it runs MSAccess.exe, it will pass the location as a
command line parameter. Every database file can have a different resource
folder associated with it.
4) It will look into the resource folder for a newer version of the
front-end file than exists on the PC. If one exists, it will replace the
older version with the newer version.

With command line options, you can get different variations on this
behavior, but that's the meat of it. I created a help file with all the
details. Together, these features make deployment a snap. Rolling out
revisions become trivial -- you just put the new front-end file in the
resource folder.

Please give me comments. If some fraction of the coders on this newsgroup
find the AccessAppStarter as helpful as I do, I may begin to repay the huge
debt I owe after years of posting questions here.
-Todd Matson

[Rick Brandt]

"Todd Matson" <v@x.z> wrote in message news:tmPYd.7336$ju.7230@okepread07...

A couple of years ago, I wrote a program I call the AccessAppStarter to help
me deploy Access applications. Since then, it has become indispensable to
me. I've used it with every Access application I've written. I was
reflecting on this today when it occurred to me that other developers might
find it useful too, so I've posted it at
http://MatsonConsulting.com/download...appstarter.zip for everyone to
use. If someone can tell me how to release software with an open source
license, I'll post the source code too.

What the program does is very simple. Instead of running MSAccess.exe with
the front-end file as a command line parameter, you instead run
AccessAppStarter.exe with the front-end file as a command line parameter.
AccessAppStarter will then run MSAccess.exe, but before it does it will
perform a few useful functions:
1) It will check the registry to see if it knows the location of the
workgroup file. If it doesn't, it will prompt the user for the location and
save it to the registry. Then, when it runs MSAccess.exe, it will use the
workgroup file. Every front-end file can have a different workgroup file
associated with it.
2) It will check the registry to see if it knows the location of the
back-end data file. If it doesn't, it will prompt the user for the location
and save it to the registry. Then, when it runs MSAccess.exe, it will pass
the location as a command line parameter. Every front-end file can have a
different back-end file associated with it.
3) It will check the registry to see if it knows the location of the
resource folder. (The resource folder is a place on the network where the
front-end will look for expected files, or where it can write shared data.)
If it doesn't, it will prompt the user for the location and save it to the
registry. Then, when it runs MSAccess.exe, it will pass the location as a
command line parameter. Every database file can have a different resource
folder associated with it.
4) It will look into the resource folder for a newer version of the
front-end file than exists on the PC. If one exists, it will replace the
older version with the newer version.

With command line options, you can get different variations on this
behavior, but that's the meat of it. I created a help file with all the
details. Together, these features make deployment a snap. Rolling out
revisions become trivial -- you just put the new front-end file in the
resource folder.

Please give me comments. If some fraction of the coders on this newsgroup
find the AccessAppStarter as helpful as I do, I may begin to repay the huge
debt I owe after years of posting questions here.

Sounds like you did some nice work. My only comment is that (almost) none of my
users would be able to answer a single one of those prompts.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Todd Matson]

Rick,

Mine neither, but that's the beauty of the program. When you first install
your application on each PC, you run AccessAppStarter and answer the prompts
yourself. After that, the values are stored in the registry, so they persist
even through successive revisions. The program doesn't add to the confusion
of finding supporing files; on the contrary, it completely eliminates such
confusion!

-Todd Matson
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:39*************@individual.net...

Sounds like you did some nice work. My only comment is that (almost) none of my users would be able to answer a single one of those prompts.

[Rick Brandt]

"Todd Matson" <v@x.z> wrote in message news:Wg_Yd.8006$ju.5527@okepread07...

Rick,

Mine neither, but that's the beauty of the program. When you first install
your application on each PC, you run AccessAppStarter and answer the prompts
yourself. After that, the values are stored in the registry, so they persist
even through successive revisions. The program doesn't add to the confusion
of finding supporing files; on the contrary, it completely eliminates such
confusion!

But the only users I have that are using an MDB as the back end are remote so
they are doing the install themselves.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Todd Matson]

Rick,

I won't make the mistake of claiming the program is useful in all
circumstances. When the following are true, however, I find it to be very
helpful:
1) The application uses one or more shared files (a custom workgroup file, a
back-end file, etc.).
2) The paths to the shared files are different in the development
environment and the production environment. They may even be different from
PC to PC on the production network.
3) You need to roll-out several revisions while the app is in production.

Under these conditions, you must somehow tell your application where to find
the shared files. You will have that problem whether you use
AccessAppStarter or not. If you use AccessAppStarter, however, you need to
solve the problem only once per PC instead of once per revision.

In response to your comment, I will argue that when the above conditions are
true, AccessAppStarter simplifies remote installations. If the conditions do
not apply to your projects, however, I will gladly concede that
AccessAppStarter may not help you.
-Todd Matson
"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:39*************@individual.net...

"Todd Matson" <v@x.z> wrote in message news:Wg_Yd.8006$ju.5527@okepread07...
But the only users I have that are using an MDB as the back end are remote so they are doing the install themselves.