Distributing Database Changes

[khood]

Looking for suggestions/thoughts, please.

I have an application that is distributed to about 25 outside locations. The front-end is an MDE. This application has evolved considerably over 2 years, and some clients have older versions than others (3 different versions). Upgrades have been handled on an individual basis using queries, but with many more new installs coming up, I am looking for a more automated solution.

My newest distribution procedure utilizes Access Runtime Minimum. I have partially written a separate application to handle the data conversion. I have created a "schema" table that has all of the information necessary for the new table structure. My initial plan was to check each field in the old database & modify/add the field to the table, if necessary.

What is the preferable approach, modify existing tables by adding/changing fields (as above), or rename the old database and import/query the data into the new one using a map for each field?

Notes: I want both sides of the conversion to remain somewhat "variable". In other words, I don't want hard-coded queries to handle everything. Even though I have several old versions of the database, I only want 1 conversion program. Also, I have several autonumber fields that, if changed, must cascade throughout the database.

Thanks in advance for you help,
Ken

 

[930driver]

I would be inclined to loop through your schema table and make changes as necessary. It seems to me that this way all versions could be brought up to date. I don't see much advantage to creating a new database unless you have datatype conversions. In this case you'd have to create a new field, copy data over and then delete the old or risk losing data. New fields, of course, wouldn't need the new database.

Do you have a demo of your process that you'd be willing to share? I'm facing the same thing, but haven't had time to devote to developing the update stuff. "The Key, The Whole Key, and Nothing But The Key, So Help Me Codd!"