Because Firebird uses different strategies for different kinds of queries,
it is generally not possible (for the server) to determine the row count in advance,
without fetching all rows.
For this reason isc_dsql_sql_info() call will return number of rows
already sent from the server to client (they are usually sent in batches,
and cached by client library).
You can notice that the number of rows fetched in one operation (1302)
will vary depending (among other things) on the width of result set.

Ivan Prenosil
[ I am looking for a job: InterBase - Firebird - Delphi - C - fulltext db - and more ... ]
Ivan.Prenosil@...
http://www.volny.cz/iprenosil/interbase

----- Original Message -----
From: "davidrushby" <davidrushby@...>


> I'm using the C API function isc_dsql_sql_info with the request code
> isc_info_sql_records to determine the row count from a SELECT
> statement on a table (a plain table, not a selectable stored proc or a
> view).
>
> Ordinarily, the row count is 0 from the time the SELECT statement is
> executed until at least 1 fetch has been performed, then the real row
> count can be determined. This is expected.
>
> With large result sets, however, the row count is misreported. The
> threshold on both FB 1.0 and FB 1.5-RC2 is 1302 rows; any SELECT that
> returns more than 1302 rows but less than 2605 rows has the row count
> misreported as 1302 until at least 1303 rows have been fetched, at
> which point the row count is reported correctly again. The next
> threshold after 1302 is 2604, then 3906, 5208, ...
>
> Because of that pattern, I'm assuming that result sets are marshalled
> within the server in batches no larger than 1302 rows at a time; until
> a batch has been marshalled, its contents are not included in the row
> count returned by isc_dsql_sql_info. Is my assumption correct?