Sending out upgrades

[Mus' via AccessMonster.com]

I have a created a useful .mdb which serves as a tool to a number of
remote/non-networked users.

I would like to be able to send out a disk that the user can then use to
upgrade their version to the latest .

I am not looking for an explicit answer as I realise this is too large a
topic but I would welcome being pointed in the right directions. I believe
that this falls into two key areas:

1) I realise that I must give special consideration to how I set up of the
original database.
2) I need to learn about the process/method of the upgrade itself.

I guess the key comes down to tables and their relationships. As long as
these do not alter then I guess the migration is simpler but what if you need
to amend the tables??

Anyway, any pointers appreciated.

 

[Rick Brandt]

I have a created a useful .mdb which serves as a tool to a number of
remote/non-networked users.

I would like to be able to send out a disk that the user can then use
to upgrade their version to the latest .

I am not looking for an explicit answer as I realise this is too
large a topic but I would welcome being pointed in the right
directions. I believe that this falls into two key areas:

1) I realise that I must give special consideration to how I set up
of the original database.
2) I need to learn about the process/method of the upgrade itself.

I guess the key comes down to tables and their relationships. As long
as these do not alter then I guess the migration is simpler but what
if you need to amend the tables??

Anyway, any pointers appreciated.

Your app should (always) be split. Tables in one file, everything else in the
other. Doing so means revisions that do not involve changes to the tables only
require that you replace the "front end" file with the new one and provide code
in the new one for re-linking to the existing "back end" file.

What I do for changes to the tables...

If the changes are extensive I install a new back end file and there is "run
once" code in the new front end file that imports all of the data from the old
back end into the new one. If the changes are not extensive I execute "run
once" code in the new front end that actually makes the modifications to the
table programmatically.

 

[Mus' via AccessMonster.com]

Thanks Rick, that gives me somewhere to start.

Your app should (always) be split. Tables in one file, everything else in the
other. Doing so means revisions that do not involve changes to the tables only
require that you replace the "front end" file with the new one and provide code
in the new one for re-linking to the existing "back end" file.

What I do for changes to the tables...

If the changes are extensive I install a new back end file and there is "run
once" code in the new front end file that imports all of the data from the old
back end into the new one. If the changes are not extensive I execute "run
once" code in the new front end that actually makes the modifications to the
table programmatically.