Re: CDR CHECK -R returns error

Peter, Check if your sql script for checksum routines registration includes the next two routines create function checksum(p1 blob, p2 integer) RETURNS integer with (NOT VARIANT, HANDLESNULLS, PARALLELIZABLE) EXTERNAL NAME "$INFORMIXDIR/udrs/checksum.so(sblob_checksum)" LANGUAGE C; create function checksum(p1 clob, p2 integer) RETURNS integer with (NOT VARIANT, HANDLESNULLS, PARALLELIZABLE) EXTERNAL NAME "$INFORMIXDIR/udrs/checksum.so(sblob_checksum)" LANGUAGE C; Regards "Peter Langseth" <pel@djoef.dk> wrote in message news:1168007792.765969.252400@38g2000cwa.googlegroups.com... > Hi > > I am trying to set up an Enterprise Replication on an IDS 10.0 UC5 with > tables using clobs and blobs. > > Everything is working fine including the "cdr check replicate -c server > -m master -r repl target" commands, but when I add the -R option to get > the inconsistencies repaired the cdr check returns the following error: > > [informix@fjalar check]$ cdr check replicate -c g_galar -m g_fjalar -r > cw_pub_artikel g_galar -R > ------ Statistics for cw_pub_artikel ------ > ERROR Code -937 Isam 0 File replcheck.ec Line 4327 > performDelete > > User Defined Routine error. > > Does anyone know what could be wrong? > > Kind Regards > Peter Langseth >

Hi Yes i have created the extra checksum functions for blob and clob, and i've checked that the checksum.c file that i've compiled is the one located here: http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0604pruet/ so im pretty sure im running with the correct versions. I've checked the informix message log files at the times the cdr check is running and the only information there is the following: 11:59:25 RESYNC: Setting Replicate 2686990 to Normal mode I've also checke the ATS/RIS files and there no additional info there. I found the row that couldn't be deleted, and checked that i wasn't locked for some reason, and i could delete it manually. After that the cdr check -R ran without problems. On other tables that are being replicated the same problem seem to occur, sometimes the cdr check -R can delete some of the extra rows, and sometimes it returns the error. I can't seem to figure out why, as the rows do not seem locked after the error occurs. Is there any extra tracing that can be enabled so i can find the cause of the error in performDelete? Kind regards Peter

Peter, take into account that "cdr check" and "cdr sync" are quite new features and have to be polished. As long as basic ER works (and it does, very well), I'm happy (because my customers are happy). <SNIP> > On other tables that are being replicated the same problem seem to > occur, sometimes the cdr check -R can delete some of the extra rows, > and sometimes it returns the error. I can't seem to figure out why, as > the rows do not seem locked after the error occurs. Does it occur randomly, or the error always occurs on specific tables while other tables in ER always succeed? Because I have somewhat similar situation (although not while deleting) so we might spot a problem together... Regards Davorin

It seems to be certain tables that have problems deleting, tho i need more time testing before i can be sure. But yes the basic replication works very well and has really good performance, so that is very nice. But it would be very cool, if the check/repair functions where more reliable so we could have near-zero manual maintenance. Kiind regards Peter

> It seems to be certain tables that have problems deleting, tho i need > more time testing before i can be sure. Peter, check the differences between schemas of tables which succeed with those that don't. For example, I have problems with tables which use user-defined unique indexes for their primary keys. All other tables are fine. Although I'm quite sure it's not relevant to your case. Check what Madison said. > But it would be very cool, if the check/repair functions where more > reliable so we could have near-zero manual maintenance. Yes, DBA's dream. But what would all "consultants" do if there were no bugs in software? :o)

Hi >Based on this error, it appears that the UDRs to a UDT returned some >error status when we were trying to delete an extra row on one of the >target servers. Do you have any UDTs on the replicated table which you >are wanting to perform the sync option. The tables that are being replicated use clobs and blobs. (not sure if those are considered UDTs)? The tables are not using datatypes we have defined ourselves. >If you want, you can get a trace of cdr check by setting the environment >variable "MyTrace=1". This will cause a bunch of tracing to go to STDERR. I tried with the trace on, but the trace didn't give any new clues to the error. The trace just ends with: "ERROR Code -937 Isam 0 File replcheck.ec Line 4327 performDelete User Defined Routine error." >Peter, check the differences between schemas of tables which succeed with >those that don't. >For example, I have problems with tables which use user-defined unique >indexes for their primary keys. All other tables are fine. I've checket that too, but all the tables use the indexes that are autocreated when the primary keys are created. But since i can manually delete the extra rows, it seems to me that maybe the cdr check locks the rows and then maybe can't delete them (weird if its the same transaction). >Yes, DBA's dream. >But what would all "consultants" do if there were no bugs in software? :o) Aye indeed, but it would be beautiful :) Kind regards Peter

Peter Langseth wrote: > Hi > >> Based on this error, it appears that the UDRs to a UDT returned some >> error status when we were trying to delete an extra row on one of the >> target servers. Do you have any UDTs on the replicated table which you >> are wanting to perform the sync option. > > The tables that are being replicated use clobs and blobs. (not sure if > those are considered UDTs)? > The tables are not using datatypes we have defined ourselves. > >> If you want, you can get a trace of cdr check by setting the environment >> variable "MyTrace=1". This will cause a bunch of tracing to go to STDERR. > > I tried with the trace on, but the trace didn't give any new clues to > the error. The trace just ends with: > "ERROR Code -937 Isam 0 File replcheck.ec Line 4327 > performDelete Do you have a case open? If not, then please open one. Include the output of dbschema, the tables involved in the sync, and the output of the trace. > > User Defined Routine error." > >> Peter, check the differences between schemas of tables which succeed with >> those that don't. >> For example, I have problems with tables which use user-defined unique >> indexes for their primary keys. All other tables are fine. > > I've checket that too, but all the tables use the indexes that are > autocreated when the primary keys are created. > > But since i can manually delete the extra rows, it seems to me that > maybe the cdr check locks the rows and then maybe can't delete them > (weird if its the same transaction). > >> Yes, DBA's dream. >> But what would all "consultants" do if there were no bugs in software? :o) > Aye indeed, but it would be beautiful :) > > Kind regards > Peter >