All primary keys were meaningless, a 9 digit number, and generated from a sequence by a pre-insert trigger. Because of some home-grown GUI program, used in the project, the key needed to be unique in the whole set of tables, so onde qequence was used. Ordering was important, gaps were no problem. The same pre-insert-trigger would find a non-null primary key when the record came from the replication process. If a non-null primary key was found, it would start a loop hammering the sequence until it reached the same id as the id just received. So we enforced synchronisation between both sequences, without the need of having them started at different offsets, which would have violated the 'ordered constraint' needed by the GUI-stuff.
Carel-Jan
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Carel-Jan Engel INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
