You cannot depend on the value in sqlca.sqlerrd[2] until the last row was
returned from the server. I'm guessing that 92 is the number of rows that
fits into a default sized (4K) communications buffer and so when the engine
returns that first buffer to the ESQL/C library it already contains the
last row and so the count has been updated. If there are more rows than fit
into a single buffer, then the count in sqlca.sqlerrd[2] will not be updated
until the buffer containing the last row is returned from the engine. You
could expand the comms buffer size with the FET_BUF_SIZE environment
variable or by setting the fetbusize global variable immediately after
connecting to the database but before any DML is issued. You can set the
buffer up to 32765 bytes which would hold over 1500 rows in a single
physical fetch, but someday you might exceed that and then your reliance on
this value will fail again.

If you need the count before counting them yourself in the code you will
need to execute an identically (or at least equivalently) filtered query
that returns just the COUNT(*). You don't need the count to regulate the
FETCH loop, you can do that using the "(sqlca.sqlcode == SQLNOTFOUND)" test
or its inverse to manage the loop. For pre-sizing an array to fetch data
into, you'll have to either go the COUNT(*) route, or dynamically resize the
array as you go. I have many apps like that where I allocate an array big
enough for most runs and if there is more data I reallocate the array with
an additional block of N more rows and again if I've exhausted the extra
space, etc.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art (AT) iiug (DOT) org)

See you at the 2010 IIUG Informix Conference
April 25-28, 2010
Overland Park (Kansas City), KS
www.iiug.org/conf

Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.



On Fri, Mar 5, 2010 at 10:22 AM, Peter Michel <
proORGA-Leimen.without-this (AT) web (DOT) de> wrote: