Anyone have experience with dbUpgrader or other ways to upgrade back end?

[j.mandala]

Various versions of my app have been in use for the last 5 years or so
(in Access 97, 2K and XP editions). To upgrade the back end for people
I have to add fields to some tables, some new indexes, and a few
tables.

I have been looking at the dbUpgrader demo (the ActiveX device), but
have not been able to get it to work. Before I spend a lot of time on
this I was wondering if anyone had any suggestions on whether this is
worthwhile or if people use other ways to upgrade back ends.

This is my only application. It is low cost and I don't want to invest
a lot of money into tools to do this. I need to be able to send
something to people over the web. I can usually talk them through
installing something simple...

As usual, thanks in advance for sharing your wisdom.

Jim Mandala

[Tony Toews]

ma*****@rci.rutgers.edu (j.mandala) wrote:

I have been looking at the dbUpgrader demo (the ActiveX device), but
have not been able to get it to work. Before I spend a lot of time on
this I was wondering if anyone had any suggestions on whether this is
worthwhile or if people use other ways to upgrade back ends.

You have two basic methods of doing version upgrades to the backend MDB.

1) Ship a new empty MDB and copy the tables across in relational sequence, ie parent
records, then child tables and so forth down and across the "relational tree:" This
can be done by creating a table containing the table names with a relational sequence
field and running down the tables doing append queries.

Where appropriate you will need to copy specific fields to other tables to split data
out given new tables.

2) Create a bunch of code within your new version which creates the new tables,
relationships and new fields on existing tables. Then copy the records across from
old versions of tables to the new versions and delete the superflous fields.

Neither process is simple.

In both cases I would suggest keeping a version number of the FE and BE in a table or
property thus helping you to figure out when to run the code or not allow a new FE to
be run against an old format BE.

Also make a backup before doing any such updates, double check the number of records
in the new tables after the conversion and include a mechanism to ensure users aren't
in the backend when all this starts or during the process.

Clearly this is not going to be a simple task. <smile>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[j.mandala]

I had not thought of trying your firstr approach. I usually send
people a model back end and talk them through adding fields and
importing tables. dbUpgrader is an activeX device that you put on a
form. It's methods let it compare a back end with a model and then it
automatically updates the old data file. Renaming, adding or importing
as you specify with very little coding. If only I could get it to
work...

Sigh! I may give your first method a try. That would deal with the
problem I have - i.e there are many versions of the back end up there
and I don't have good record of who has what. Clearly I am an amateur!

Thanks for the suggestions.

Jim

You have two basic methods of doing version upgrades to the backend MDB.

1) Ship a new empty MDB and copy the tables across in relational sequence, ie parent
records, then child tables and so forth down and across the "relational tree:" This
can be done by creating a table containing the table names with a relational sequence
field and running down the tables doing append queries.

Where appropriate you will need to copy specific fields to other tables to split data
out given new tables.

2) Create a bunch of code within your new version which creates the new tables,
relationships and new fields on existing tables. Then copy the records across from
old versions of tables to the new versions and delete the superflous fields.

Neither process is simple.

In both cases I would suggest keeping a version number of the FE and BE in a table or
property thus helping you to figure out when to run the code or not allow a new FE to
be run against an old format BE.

Also make a backup before doing any such updates, double check the number of records
in the new tables after the conversion and include a mechanism to ensure users aren't
in the backend when all this starts or during the process.

Clearly this is not going to be a simple task. <smile>

Tony