Grigore Dolghin wrote: > I completely, wholehearted, 100% agree. GUID is the WAY to go - > started using them as PKs back in 2004 I think, when I was asked to > unify the databases of a program created by me and installed initially > in two different locations. 1 year later they came and said "well, > Grig, can you put them together?". Guess what, they were using > integers identity as keys. Well, I was pretty much f*cked up for one > week or so, writing scripts to re-sync those damn integers. Moved to > GUIDs and never looked back. >
I'm certainly not getting it. Go to destination location and add a field named original_pk then append records from origin location putting the origin pk in original_pk (the actual pk will be autoincremented in destination). Then as you append the other tables (the ones that have pk as a foreign key) you check the pk/original_pk as a translation table and correct the reference and that's it. Of course it will get a bit more complicated as you'll have the same problem with mostly every table, but if you think it through a bit and get organized it's not such a big deal. The only concern is to start with the tables that have no foreign references and build it up from there (as there never are circular references in a proper built db). _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
