Enterprise Rep on NT

Dear Informixers, This is a challenging question, so if you can stay with it to the end you'll have achieved half the battle ! We have 2 NT servers 4.0 SP6 running Enterprise Replication on IDS 7.31.TC6. For simplicity sake, we have one table that is causing a little trouble. Lets call this the 'transaction' table. The transaction table has the following columns:- generator serial primary key, term_inf smallint, reference char(10), etc... Transactions are being sent and processed by these NT servers in a Round Robin fashion i.e. we have a 'splitter' which governs which NT server should process the next transaction. NT1 starts with a serial number of 0, NT2 starts with a serial No of 5000001. How can we replicate the transactions such that the generator serial number only every gets updated by 1 and NOT set to the serial number of the source db server ? i.e. if NT1 replicates a transaction where generator = 0002, it gets replicated to NT2 as 5000002, and thus, if NT2 has a transaction such that generator = 5000067, NT1 should set the generator field to 0003. All answers, as ever, very much appreciated. Cheers S. Sent via Deja.com http://www.deja.com/ Before you buy.

Afraid that you can't. The primary key is used by ER to identify the row and as such is replicated to the central server. If the central server were to store this row with a different primary key, then there would be no way that a subsequent update on the row would be correctly replicated. If you really need to have a incremental field on the central server, then you might be able to do somthing like: On remote system... Create table A ( col1 serial column primary key, col2 .... ); On Central system... Create table A ( col1 int primary key, col1a serial col2 .... .... Then define the replicate as select col1, col2.... N.B. by leaving out col1a on the central system, it will be filled with the serial column on that central system. sean.kelsey@2020log.com wrote: > Dear Informixers, > > This is a challenging question, so if you can stay with it to the end > you'll have achieved half the battle ! > > We have 2 NT servers 4.0 SP6 running Enterprise Replication on IDS > 7.31.TC6. For simplicity sake, we have one table that is causing a > little trouble. Lets call this the 'transaction' table. > > The transaction table has the following columns:- > > generator serial primary key, > term_inf smallint, > reference char(10), > etc... > > Transactions are being sent and processed by these NT servers in a > Round Robin fashion i.e. we have a 'splitter' which governs which NT > server should process the next transaction. NT1 starts with a serial > number of 0, NT2 starts with a serial No of 5000001. > > How can we replicate the transactions such that the generator serial > number only every gets updated by 1 and NOT set to the serial number of > the source db server ? i.e. if NT1 replicates a transaction where > generator = 0002, it gets replicated to NT2 as 5000002, and thus, if > NT2 has a transaction such that generator = 5000067, NT1 should set the > generator field to 0003. > > All answers, as ever, very much appreciated. > > Cheers > > S. > > Sent via Deja.com http://www.deja.com/ > Before you buy.

sean.kelsey@2020log.com wrote: > We have 2 NT servers 4.0 SP6 running Enterprise Replication on IDS > 7.31.TC6. For simplicity sake, we have one table that is causing a > little trouble. Lets call this the 'transaction' table. > > The transaction table has the following columns:- > > generator serial primary key, > term_inf smallint, > reference char(10), > etc... > > Transactions are being sent and processed by these NT servers in a > Round Robin fashion i.e. we have a 'splitter' which governs which NT > server should process the next transaction. NT1 starts with a serial > number of 0, NT2 starts with a serial No of 5000001. > > How can we replicate the transactions such that the generator serial > number only every gets updated by 1 and NOT set to the serial number of > the source db server ? i.e. if NT1 replicates a transaction where > generator = 0002, it gets replicated to NT2 as 5000002, and thus, if > NT2 has a transaction such that generator = 5000067, NT1 should set the > generator field to 0003. "Guide to Informix Enterprise Replication", p. 4-10: A serial-column key cannot be a primary key by itself. We are using approach followed. Each database has table 'identifiers' CREATE TABLE identifiers ( tabname CHAR( 18 ) NOT NULL PRIMARY KEY, last_inserted_pk INT NOT NULL );This table on first server is filled as: transaction|0 but on second: transaction|50000000 Inserting a row into 'transaction' table on both servers could be: BEGIN WORK; UPDATE identifiers SET last_inserted_pk = last_inserted_pk + 1 WHEREtabname = 'transaction'; SELECT last_inserted_pk INTO :int_var FROM identifiers WHERE tabname = 'transaction'; INSERT INTO transactions ( pk, ... ) VALUES ( :int_var, ... );COMMIT;

Never mind all that informix stuff ....what about the mancs getting there arses kicked in Europe!!!!!! <sean.kelsey@2020log.com> wrote in message news:8t6vu9$ft2$1@nnrp1.deja.com... > Dear Informixers, > > This is a challenging question, so if you can stay with it to the end > you'll have achieved half the battle ! > > We have 2 NT servers 4.0 SP6 running Enterprise Replication on IDS > 7.31.TC6. For simplicity sake, we have one table that is causing a > little trouble. Lets call this the 'transaction' table. > > The transaction table has the following columns:- > > generator serial primary key, > term_inf smallint, > reference char(10), > etc... > > Transactions are being sent and processed by these NT servers in a > Round Robin fashion i.e. we have a 'splitter' which governs which NT > server should process the next transaction. NT1 starts with a serial > number of 0, NT2 starts with a serial No of 5000001. > > How can we replicate the transactions such that the generator serial > number only every gets updated by 1 and NOT set to the serial number of > the source db server ? i.e. if NT1 replicates a transaction where > generator = 0002, it gets replicated to NT2 as 5000002, and thus, if > NT2 has a transaction such that generator = 5000067, NT1 should set the > generator field to 0003. > > All answers, as ever, very much appreciated. > > Cheers > > S. > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.