Database File Merge?

[vwgtiturbo]

Hello,

The forum search is failing me, and Google is yielding old results, so I figured that I'd take a shot in the dark here...

I built a fairly complex database a few months ago, and sent it to my counterparts at overseas locations to use until I can implement one last (time-consuming) section.

I am working on applying fixes to existing formulas/layouts, and adding new scripts/layouts/tables to a "Master" DB file. But it occurred to me that applying all of these changes would be nearly impossible for the other DB files (as far as ensuring that ALL changes are implemented across the other files, etc.). Is there a guide outlining the process for merging a user's existing DB data with my new 'fixed/improved' copy? Even though I'm dealing with 100 tables, I have no problem emptying all of the tables and resetting auto-increment record serials if necessary. From what I can find, it looks to be a tedious process (which I really don't mind), but am wondering if it is even possible to do this, while keeping record numbers/data integrity in tact across the 'new' DB file and their existing 'old' copy.

Even a tedious import of the other user's DB data would likely be much easier than attempting to recreate all of the fixes/new design points a second time into their DB.

Thanks in advance for any push in the right direction. I just didn't want to blindly follow one source's recommendation, and end up neglecting some aspect that wrecks the DB information already compiled.

Edited November 2, 2017 by vwgtiturbo
Word clarification

[rwoods]

In my experience then the only way is to make a note of the next value of any auto-enter serials, and then just manually import the data from the old files' tables into the new files' tables. Then set the next serial value appropriately in the new file.

Using a data separation model is one way to avoid this, by keeping the UI separate from the data tables. However if you have been making wholesale changes, then it is likely that the old data file would need to be manually changed to match your new version, so you would still have to have kept a note of any changes made to the data file and reproduce them.

At least you only have to do it once...

[bcooney]

There exist some tools to help with a version update. Yes, data separation is an approach and I've had it work well. I've also scripted the import. If you go that route, I posted a demo a long time ago of an upgrade script: thread about updating w/demo file

Look at the new product from 360works: Deploy

This has been around a while, but I don't have first-hand experience: RefreshFM

[vwgtiturbo]

2 hours ago, bcooney said:

There exist some tools to help with a version update. Yes, data separation is an approach and I've had it work well. I've also scripted the import. If you go that route, I posted a demo a long time ago of an upgrade script: thread about updating w/demo file

Look at the new product from 360works: Deploy

This has been around a while, but I don't have first-hand experience: RefreshFM

Thanks for the 360Works link! Over the course of time and subsequent revisions/fixes/additions, the cost of this software could pay for itself easily if it works out well!

3 hours ago, rwoods said:

In my experience then the only way is to make a note of the next value of any auto-enter serials, and then just manually import the data from the old files' tables into the new files' tables. Then set the next serial value appropriately in the new file.

Using a data separation model is one way to avoid this, by keeping the UI separate from the data tables. However if you have been making wholesale changes, then it is likely that the old data file would need to be manually changed to match your new version, so you would still have to have kept a note of any changes made to the data file and reproduce them.

At least you only have to do it once...

Thanks for that tip! I honestly had never heard of data separation (this is my first complex database; all others have been single-user flat-file type). I wish I would've thought of this before fielding the database to begin with, hahaha.