At 05:37 AM 13-01-02 +0100, you wrote:

>Hi,
>
>sorry, got to bother you again.
>
>Finally I found out that calling isc_dsql_sql_info with isc_info_sql_records
>delivers me the count of affected or selected rows, depending on the type of
>the statement; to find out how many rows are in the result set of a SELECT
>statement requires to call isc_dsql_fetch at least one time. My question is
>now, why is it not documented? Is it unreliable?
>

Uwe,

First, with these accursed manuals, don't assume that, if you can't find something in the Index, it's undocumented. The indexing and organisation of these manuals are frightful. The isc_info_sql_records member IS documented somewhere among those books - I know, because I saw it recently when looking up something else.

Is it unreliable? yes; or perhaps it's better to say "make sure you understand what you are getting back". Probably the only way you could get a definitive answer will be to test statements yourself, keep notes and make yourself a reference sheet. (If you do, I'd be very glad to publish it in the Really Useful pages ! <g>) It varies according to statement type and, in the case of stored procedures, it might not predictably count, e.g. simply the iterations of a FOR..SELECT..INTO loop, but it might add in the rows it touched in other tables if the SP is complex.

There's currently a request to fix it so that, for each type of statement, we know what we are going to get back and what we get back will be actually be useful for something...it's not a Release 1 task, though.

regards,
Helen

All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________