TWIMC,

In following up after trying to figure out in advance the N of Tuples
returned from a dsql select statement, I've proceeded to the API reference
where it explains that the isc_set_cursor_name() follows the
isc_dsql_execute() call, but after closing the cursor with
isc_free_statement( ... DSQL_close ), one might simply do another
isc_set_cursor_name() to re-select ...

pseudo code is like:

... initial stuff done correctly (queries work ok 1x).

isc_dsql_execute( with NULL OXSQLDA )
isc_set_cursor_name( ... "q_Cursor" )
while( isc_dsql_fetch() == 0 ){
/* this far it works OK */
}
isc_free_statement( ... DSQL_close ) /* close cursor */
isc_set_cursor_name( ... "q_Cursor" ) /* re-open cursor */
while( isc_dsql_fetch() == 0 ){
/* fails */
}
/*
*** Error 504
- Dynamic SQL Error
- SQL Error code -504
- Unknown Cursor
*/

This is the correct sequence implied in the Interbase API guide, but I wonder
whether the isc_dsql_execute() needs to be redone, or what. I seem to be
able to get the records appropriately the first time, but the second time
I get the 504 error.

After nuking the statement, and preparing another ... the next select works
just fine ...

The reason I need this, is to determine on the first pass the number of tuples
retuned by the query, and thus to cache efficiently the results on the 2nd
pass.

Thanks in advance for any pointers ...

Cheers,
Rob