Ronnie, I was just reading through the thread here. I did a similar migration when I moved a database from v2004 to v13. In that case the v13 database was a major re-write of the original. There were significant differences in the new structure including removing a couple of subtables. And there was even a case where data from two tables were collapsed into a single one requiring some careful attention to the ID numbers. As I say, it was a rewrite.
My approach was to build the export methods in the old database. It's much easier to manipulate that data in its own environment. Set up the export methods to created documents that can be imported into the new tables. I included setting/synching ID numbers in this operation. You can use SET DATABASE PARAMETER to correct id sequence numbers after import. Some tables may export as is. Great. Do it using the same process anyway. I found it easier to resolve structure issues in the old db during the export than anywhere else. This is also a chance for you to clean up things like created/modified fields that may be different in the new db. On the import side you need to pay attention to setting a flag that your trigger methods check if you have a lot of processing going on there. And you can manage any other conversion chores that you couldn't manage on the export side. I used simple tab/cr export files. If you have text fields that may include tabs or CRs encode them on the export side (I use <tab> and <cr> to keep it simple) and decode them on the import side. I prefer this to CSV simply because CSV can get tricky with text fields containing quotes. I found this process useful. As I said it's easier to do transformations and make changes to the data on the export side. Putting your data into files that can be more or less directly imported helps you spot errors pretty quickly. And I found it much easier to write import methods that dealt with the data in the context of the new structure. Granted you may wind up with some pretty slow methods. But they only need to run once. And the importance of accuracy outweighs the time. At least in my case. On Mon, Apr 29, 2019 at 11:53 PM Ronnie Teo via 4D_Tech < [email protected]> wrote: > Hi All, > > A client has requested to decommission a v13 database and merge the data > into a separate v15 database. > The 2 database structures started the same (as in same tables and fields) > but has expanded in different directions down the years. > It would be fair to say that the fields in the v13 structure would be a > subset of the v15 structure. > > A send/receive record option would not be feasible. > Tinkling with some ideas, perhaps exporting table data to CSV file (from > v13) and import into v15. > Or perhaps just exporting individual tables (individual) fields to text > files with custom delimiters…. > > What would be the best way to accomplish this? > > Regards, > Ronnie > Tarawerkz > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** -- Kirk Brooks San Francisco, CA ======================= What can be said, can be said clearly, and what you can’t say, you should shut up about *Wittgenstein and the Computer * ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
