Here is a little from the online help for TIB_Dataset...

- - -
The RecordCount property may not work for some select statements
either. It uses a simple parsing substitution in order to put together
a separate SELECT COUNT( * ) statement to get the record counts. You
can provide a custom event handler to calculate the RecordCount for a
dataset like this. In some cases with the buffered dataset it will do
a fetchall and then report the number of record in the buffer.
- - -

So RecordCount does not actually retrieve all records back to the
client. It forms its own SQL statement derived from the supplied
statement and performs a COUNT(*) - which means that all records are
read, but at the server, not returned to the client. So the overhead
is significant but still smaller than doing a FetchAll **IF** all you
want to is know how many records there are (but then you would be
better off writing your own DSQL to obtain such information).

Given how complex SQL selects can be, it is easy to create statements
that can confuse the simple parsing mechanism used by the RecordCount
function. I would suggest that it is impractical to try and make the
RecordCount more elaborate - given the possible workarounds below.

If you really need to use RecordCount then you have two mechanisms
which can ensure accurate results...

* Use the supplied OnGetRecordCount event to perform your own count.

* Actually perform the FetchAll (in TIB_Query, a buffered dataset) and
THEN use RecordCount - which will detect that all records have been
retrieved and simply read the number of records in the buffer.


Side Note: If you are cycling through records in a loop, then see if
you can use TIB_Cursor (and a "while not Cursor.Eof" loop) instead of
TIB_Query - it much more efficient. Only use TIB_Query if you need it
for the user interface aspects.


HTH

Geoff Worboys
Telesis Computing