Re: INSERT cursor -- part two

Jonathan Leffler wrote: > > Carlson@WHSmith wrote: > > > > Added the FLUSH -- (thanks for the reminder, Gary). > > Shouldn't matter -- the CLOSE and the COMMIT both imply a flush. I was able to use the FLUSH to check sqlca.sqlerrd[3]. The sum of the FLUSH insert number and the PUT insert number should equal the number of PUTs that I executed. Hence, if they are not the same, then don't commit that transaction. Somehow, I wasn't able to check sqlca.sqlerrd[3] on a COMMIT; it always returned 0. > > > Added a row check to the number of rows processes and to > > sqlca.sqlerrd[3] after PUT and FLUSH. > > > > All seemed right with the world . . until . . . > > > > I noticed that a grouping took much longer than normal to complete. > > Cross-referenced it to the log and found that a checkpoint occurred, > > with another large update job running. > > So far, so normal. > > > From that point on, my row counts were off and no commits took place. > > Weird. > > > Any ideas about what happened? This is all so new to me . . . <G> > > Did you have WHENEVER ANY ERROR STOP set? Do you have CALL STARTLOG() > or CALL fgl_startlog() in your code? Do the log files say anything > useful? > Unfortnuately, no. But I will be doing some testing today and I'll eliminate the WHENEVER ERROR CONTINUE. I'm curious where the error (if any) would be taking place. I have sqlcode checks after each PUT; maybe that's not enough. Thanks for all your help. John Carlson Informix DBA WH Smith, Inc.