Re: SQLCA.SQLERRD[2]

Gerard Not sure I understand your question. From the Informix manuals (guide to sql, syntax) - The 'sqlca.sqlerrd2' option returns a single integer that provides the number of rows that SELECT, INSERT, DELETE, UPDATE, and EXECUTE PROCEDURE statements processed. In 4GL, if I remember correctly, the same value is returned in sqlca.sqlerrd[2]. OTOH, sqlca.sqlerrd[1] (in 4GL, again, if I remember correctly) returns the last serial number inserted. This sounds more like the problem you mention. I have never seen it return incorrect values myself, but I have heard that it can get the wrong values if an UPDATE STATISTICS has not been done lately (since you just reloaded the database,the statistics are almost certainly out of date if you haven't run it after the load). So once you fix the duplicate keys, just do an UPDATE STATISTICS on the database. It may help you solve your problem. HTH Sujit gerard <gerardm@schurmans.com> on 11/16/99 01:18:21 PM Please respond to gerard <gerardm@schurmans.com> To: informix-list@iiug.org cc: (bcc: Sujit Pal) Subject: SQLCA.SQLERRD[2] We have an application that does LET field1 = SQLCA.SQLERRD[2] field1 is an integer field In june we moved platforms so we did dbexport and dbimport to move the database to the new platform. At that time the value of SQLCA.SQLERRD[2] reverted to 1. Unfortunately it was not until now that we discovered this and we now have rows with duplicate values in field1. My question is can I somehow input a starting value for SQLCA.SQLERRD[2] and have it increment from there? Thanks -- Gerard MacNeil M.F. Schurman Company, Limited gerardm@schurmans.com http//:www.schurmans.com

In article <80ss3s$ep6$1@news.xmission.com>, Sujit.Pal@bankofamerica.com wrote: > > > Gerard > > Not sure I understand your question. From the Informix manuals (guide to sql, > syntax) - > > The 'sqlca.sqlerrd2' option returns a single integer that provides the number > of rows that SELECT, INSERT, DELETE, UPDATE, and EXECUTE PROCEDURE > statements processed. > > In 4GL, if I remember correctly, the same value is returned in sqlca.sqlerrd[2]. > > OTOH, sqlca.sqlerrd[1] (in 4GL, again, if I remember correctly) returns the last > serial > number inserted. This sounds more like the problem you mention. I have never > seen it > return incorrect values myself, but I have heard that it can get the wrong > values if an > UPDATE STATISTICS has not been done lately (since you just reloadedthe > database, > the statistics are almost certainly out of date if you haven't run it after the > load). > > So once you fix the duplicate keys, just do an UPDATE STATISTICS on the > database. It may help you solve your problem. > > HTH > Sujit > > gerard <gerardm@schurmans.com> on 11/16/99 01:18:21 PM > > Please respond to gerard <gerardm@schurmans.com> > > To: informix-list@iiug.org > cc: (bcc: Sujit Pal) > Subject: SQLCA.SQLERRD[2] > > We have an application that does > LET field1 = SQLCA.SQLERRD[2] > field1 is an integer field > > In june we moved platforms so we did dbexport and dbimport to move the > database to the new platform. At that time the value of SQLCA.SQLERRD[2] > reverted to 1. Unfortunately it was not until now that we discovered this > and we now have rows with duplicate values in field1. > My question is can I somehow input a starting value for SQLCA.SQLERRD[2] and > have it increment from there? > > Thanks > > -- > Gerard MacNeil > M.F. Schurman Company, Limited > gerardm@schurmans.com > http//:www.schurmans.com > > In ESQL/C, sqlca.sqlerrd[2]is the number of records processed following a multi-row insert, update or delete. sqlca.sqlerrd[1] is the serial value assigned to a record after an insert. I can't imagine it ever getting an incorrect serial value, since that serial value is essentially the legacy of isrecnum, and a serial column (by default, anyway) is given a unique index. -- # unrm / ksh: unrm: not found # man cpio Sent via Deja.com http://www.deja.com/ Before you buy.