H Kirk, Thanks for sharing your insight and experience.
Yes, after evaluating the feedback I’ve garnered from the list and also analysed the source and target database, I’ve more or less come back to the same position I first started with, which is to do an export from the v13 database into text files, then re-import the said files into the v15 database. Yes, it will be probably be a slow method (not to mention, tedious process to build the method) but it should be worth it if all the data can be brought over cleanly. By SET DATABASE PARAMETER, I assume you’re referring to passing current number as the value for the "Table sequence number” parameter when we import the records for each table? Regards, Ronnie Tarawerkz > On 3 May 2019, at 3:00 AM, 4d_tech-requ...@lists.4d.com wrote: > > Date: Wed, 1 May 2019 21:30:31 -0600 > From: Kirk Brooks <lists.k...@gmail.com <mailto:lists.k...@gmail.com>> > To: 4D iNug Technical <4d_tech@lists.4d.com <mailto:4d_tech@lists.4d.com>> > Subject: Re: Data Merge from v13 to v15 > Message-ID: > <CAHY=xkv5wlyca+qhnqwrn0ny8mjze4ucx_anr6ukejmzjks...@mail.gmail.com > <mailto:CAHY=xkv5wlyca+qhnqwrn0ny8mjze4ucx_anr6ukejmzjks...@mail.gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > 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 < > 4d_tech@lists.4d.com <mailto:4d_tech@lists.4d.com>> 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 >> <http://lists.4d.com/archives.html> >> Options: https://lists.4d.com/mailman/options/4d_tech >> <https://lists.4d.com/mailman/options/4d_tech> >> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >> <mailto:4d_tech-unsubscr...@lists.4d.com> >> ********************************************************************** > > > > -- > 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
