Re: INSERT cursors

Art S. Kagel wrote: . . . snip . . . > > With some difficulty. The information is available in SQLCA.SQLERRD[3] > > after each PUT which actually flushes the buffer. The value in the > > field is zero after each PUT which does not flush the buffer, so you can > > simply sum the values as you go around the loop. The real fun occurs > > after the cursor is closed at the end. Of course, if one of the PUT > > statements fails, you can (if you're careful) determine which row it was > > that failed. I'm not clear about the status of the subsequent rows, but > > I assume that they are lost. Consequently, I prefer not to use insert > > Actually, Jonathan, if there is an error in one of the PUT rows the > sqlca structure will report it when the block containing that row was > flushed. If there is an error ONLY the row(s) successfully inserted > before the row in error are successfully flushed. To recover you need > to be able to backtrack to the row following the one in error and > insert it again and perhaps log the data in error for manual recovery > later. > But within a transaction . . . shouldn't the whole transaction roll back? > By the way, to further speed up your application, Carlson, you can > increase the size of the FETCH/INSERT buffer by changing the global > variable FetBufSize which defaults to 4096 and can be increased to > 32767 (actually the closest multiple of the rowsize less than or equal > to 32767 is the effective maximum if the rowsize is smaller than > 32767). This works for 4gl 7.20.UD1 according to the release notes . . . I'll look into it. Thanks John Carlson Informix DBA WH Smith, Inc.