problem in synching a table between 2 informix ins

HI All, We have 2 instances using Informix 11.70.FC6 on linux. The instance on instance A is the source and the instance on instance B is the target; we are using ER to perform the sync. We have 483 tables to sync. - ERKEYs have been added to all of the tables - the replicates have been defined - the replicates have been started - 482 tables have been synched ONE TABLE DOES NOT WANT TO SYNC for some reason. *Here the definition of the replicate: (TABLE si the name of an individual table)* cdr define replicate --erkey -M g_edilnet_prim --scope=row -u -n n -C always ${TABLE}_replicate \\\\ "P $BASE@g_edilnet_prim:'informix'.${TABLE}" "select * from 'informix'.${TABLE}" \\\\ "R $BASE@g_edilnet_sec:'informix'.${TABLE}" "select * from 'informix'.${TABLE}" *Here is the sync command:* cdr sync repl -r ${TABLE}_replicate -m g_edilnet_prim g_edilnet_sec *Here is the schema of the table that does not want to replicate totally:* ---------------------------------------------------------------------- create table "informix".hub_ligne_commande ( id_ligne_commande serial8 not null , id_commande int8 not null , ean13 char(13) not null , gln_distributeur char(13) not null , prix_unitaire integer, quantite integer default 1, reference_ligne varchar(255) default '', retour_status varchar(255) default '', retour_message varchar(255) default '', timestamp_c datetime year to fraction(5) default current year to fraction(5) not null , timestamp_m datetime year to fraction(5) default current year to fraction(5) not null , hub_link_book_key char(32) default '' not null , platform_link_book_url varchar(255), platform_order_line_id varchar(32) ) with erkey extent size 16 next size 16 lock mode page; revoke all on "informix".hub_ligne_commande from "public" as "informix"; create unique index "informix".hub_ligne_commande_1 on "informix" .hub_ligne_commande (id_ligne_commande) using btree in idxdbs5; create index "informix".hub_ligne_commande_3 on "informix".hub_ligne_commande (id_commande) using btree in idxdbs5; alter table "informix".hub_ligne_commande add constraint primary key (id_ligne_commande) ; -------------------------------------------------------------------------------- -- *The target table gets some rows and we get the following errors in the log:* 18:15:21 CDR CDRDS: transaction aborted (Unknown error code) with sql error 268 isam error 100. 18:15:21 CDR CDRDS: transaction aborted (Unknown error code) with sql error 268 isam error 100. 18:15:21 CDR CDRDS: transaction aborted (Unknown error code) with sql error 268 isam error 100. 18:15:21 CDR CDRDS: transaction aborted (Unknown error code) with sql error 268 isam error 100. 18:15:21 CDR CDRDS: transaction aborted (Unknown error code) with sql error 268 isam error 100. ..... We have just have 103000 rows in the source table and all of the contents that are part of the PRIMARY column are of course unique. I only get some of the rows synched : sometimes 481, sometimes 100, etc. *Here is a check after trying to sync:* ------------------------------------------------------- Dec 03 2012 19:00:34 ------ Table scan for hub_ligne_commande_replicate start -------- Node Rows Extra Missing Mismatch Processed ---------------- --------- --------- --------- --------- --------- g_edilnet_prim 103465 0 0 0 0 g_edilnet_sec 100 0 7696 0 0 WARNING: replicate is not in sync Dec 03 2012 19:00:47 ------ Table scan for hub_ligne_commande_replicate end --------- command failed -- WARNING: replicate is not in sync (178) ----------------------------------------------------------------------- *After deleting all of the rows from the target table (0 rows), I get the following after a check:* -------------------------------------------------------------------------------- ---- Dec 03 2012 19:04:20 ------ Table scan for hub_ligne_commande_replicate start -------- Node Rows Extra Missing Mismatch Processed ---------------- --------- --------- --------- --------- --------- g_edilnet_prim 103465 0 0 0 0 g_edilnet_sec 0 0 8221 0 0 WARNING: replicate is not in sync Dec 03 2012 19:04:32 ------ Table scan for hub_ligne_commande_replicate end --------- -------------------------------------------------------------------------------- ---- I also used a different starting point for the SERIAL8 (the highest value known for the SERIAL8 at the source level) and the same problems happens. I took out the Primary contraint and kept the UNIQUE index, but the problem is the same. I also tried to perform a repair with the check, and not any better. ANY IDEAS ARE WELCOME !!! -- Cordialement, Regards, Khaled Bentebal Directeur Général - ConsultiX Président UGIF - User Group Informix France IIUG - Board of Directors Tél: 33 (0) 1 39 12 18 00 Fax: 33 (0) 1 39 12 18 18 Mobile: 33 (0) 6 07 78 41 97 Email: khaled.bentebal@consult-ix.fr Site Web: www.consult-ix.fr

after deleting all the rows from the target I would expect you would have the same amount of missing rows as there are rows in the source, these values are different. Try dropping and recreating the replicate. Since you have a PK, alter the table and drop the ERKEY and use the PK instead. Contact tech support for known defects as this may be something related to ERKEY good luck Mark

Thanks mark. It looks like a bug around the usage of the ERKEY with the structure of the table. After dropping the ERKEY and kept the primary key, it worked great. I did this a couple of days ago and the synchronisation is fine. The weird thing is that it is not consistent. It works for all of the other table except for this one. Cordialement, Regards, Khaled Bentebal Directeur Général - ConsultiX Président UGIF - User Group Informix France IIUG - Board of Directors Tél: 33 (0) 1 39 12 18 00 Fax: 33 (0) 1 39 12 18 18 Mobile: 33 (0) 6 07 78 41 97 Email: khaled.bentebal@consult-ix.fr Site Web: www.consult-ix.fr Le 05/12/12 16:13, MARK JALKIEWICZ a écrit : > after deleting all the rows from the target I would expect you would have the > same amount of missing rows as there are rows in the source, these values are > different. > > Try dropping and recreating the replicate. Since you have a PK, alter the > table and drop the ERKEY and use the PK instead. > > Contact tech support for known defects as this may be something related to > ERKEY > > good luck > > Mark > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >