Adam,

>
> > 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.

only way to implement ROW_COUNT would be to repeat the qury
may not help here. it doesnt work with readcommited isolation mode.
( we need a nested snapshot isolation for a pair command in this case)
some records may be deleted, some updated and some inserted in
multiuser environment...
it will equal to:
select * from foo;
select count(*) from foo;

the only valid way to count after operation is reread all cursor
buffer and count them. is FB cursors buffered or rereadable? is it a
cheap or logical way?

ROW_COUNT may be a function that returns the isolated counter
variable value. but we are not talking about current coding style.
what i said was: if you have a valid ROW_COUNT value, that proofs
you also counting result rows.

>
> 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
>

%30 transmissiýn costs for an extra 4 or 8 byte integer in SQL data
packets? i disagre at this point. FB need more serious optimisations
about client communications.
These semi% persons are not and can not be my coworkers, they are
customers.
Their brain washed with ora, their checklist is full about high level
SQL usage properties.

I'm not a computer professional at now and i won't be anymore.
i'm not even interested with IT/IS technologies other than FB.
I don't have any expectation (commertial or personal) from FB also.
It was only a cosmetic suggest.

Regards.
Ali