The few times I have had to move data from the dev database to the production one and keep already established PK/FK relations. I would disable my triggers on production and copy over the data then rebuild the sequences so they started at the next highest possible ID. That is within Oracle, never had to do it in a different DB so not sure how the process would differ. Essentially I was disabling the "auto numbering" then copy the data and re-enabling the "auto numbering". Now that method helps none if you have existing data in the new environment that has IDs that conflict with the new data.
-- Aaron Rouse http://www.happyhacker.com/ On Wed, 8 Dec 2004 08:50:42 -0600, Schreck, Tom <[EMAIL PROTECTED]> wrote: > I'm viewing this from the perspective of taking a set of data and moving it > from one environment to the next (ie, from dev to staging or staging to > production, all within the same database type). In a previous job we used > integers as PK/FK and when we went to move data we had a mess on our hands > because there's no guarantee that the integer will be unique across > databases. We had to build routines for jockeying integers when promoting > data. No fun. > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
