> ROW_COUNT is a function, defined after a succesful DML
> operation (including SELECT).

Only works with selects in FB2. In FB 1.5 it excludes selects and
execute statement DML operations.

>
> Firebird does not provide any other thing related to row numbers,
> row counts or anything.

I think the point Ali is trying to make (with some strange arguments)
is that in order to return ROW_COUNT from a select statement, it must
be adding 1 to a counting mechanism while each record is returned. A
call to ROW_COUNT simply returns this counter value. If a counting
mechanism was not maintained during the normal processing, then the
only way to implement ROW_COUNT would be to repeat the query.

Providing thie counter is somewhere accessible by the part of the
engine that is processing the fetch, it could output the current
counter value for each record. After all the sequence number of the
final record equals the ROW_COUNT. But just because a count is being
maintained somewhere, doesn't necessarily make it easy to retrieve at
a point in time, and if selects always return 0 for ROW_COUNT in FB
1.5, then there is no evidence that such a counter is even in place
until FB2.

>
> Forget the hippos, the reports, the semi-smart managers etc...

Agreed. Tell the semi-smart managers that the way they want to do
things will make it 30% slower to retrieve the records, increase data
transmission costs by 30%, increase the chance of connection dropout
during transfer by 30% and deliver no real benefits. If they still
insist on doing it a way we know is less than ideal, then they
probably don't deserve the title of semi-smart, document the
conversation where the manager has over-ruled your expertise and do as
they ask with one of the mechanisms that has been proposed (stored
procedures, context variables or selecting counts).

Do not expect developers who have useful features like asynchronous
statement cancelling and proper SMP support with SS to drop what they
are doing to develop such a feature.

Adam