AccessAppStarter

[Todd Matson]

A couple of years ago, I wrote a program I call the AccessAppStarte r 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
AccessAppStarte r.exe with the front-end file as a command line parameter.
AccessAppStarte r 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 AccessAppStarte r 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]

Re: AccessAppStarte r

"Todd Matson" <v@x.z> wrote in message news:tmPYd.7336 $ju.7230@okepre ad07...[color=blue]
>A couple of years ago, I wrote a program I call the AccessAppStarte r 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
> AccessAppStarte r.exe with the front-end file as a command line parameter.
> AccessAppStarte r 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 AccessAppStarte r as helpful as I do, I may begin to repay the huge
> debt I owe after years of posting questions here.[/color]

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]

Re: AccessAppStarte r

Rick,

Mine neither, but that's the beauty of the program. When you first install
your application on each PC, you run AccessAppStarte r 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" <rickbrandt2@ho tmail.com> wrote in message
news:39iv18F60k d7cU1@individua l.net...[color=blue]
>
> Sounds like you did some nice work. My only comment is that (almost) none[/color]
of my[color=blue]
> users would be able to answer a single one of those prompts.[/color]

[Rick Brandt]

Re: AccessAppStarte r

"Todd Matson" <v@x.z> wrote in message news:Wg_Yd.8006 $ju.5527@okepre ad07...[color=blue]
> Rick,
>
> Mine neither, but that's the beauty of the program. When you first install
> your application on each PC, you run AccessAppStarte r 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![/color]

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]

Re: AccessAppStarte r

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
AccessAppStarte r or not. If you use AccessAppStarte r, 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, AccessAppStarte r simplifies remote installations. If the conditions do
not apply to your projects, however, I will gladly concede that
AccessAppStarte r may not help you.


-Todd Matson


"Rick Brandt" <rickbrandt2@ho tmail.com> wrote in message
news:39j9tmF5vb nifU1@individua l.net...[color=blue]
> "Todd Matson" <v@x.z> wrote in message[/color]
news:Wg_Yd.8006 $ju.5527@okepre ad07...[color=blue]
>
> But the only users I have that are using an MDB as the back end are remote[/color]
so[color=blue]
> they are doing the install themselves.[/color]