> > > If flying hippopotamus AKA ora have ben supporting this for a
> long
> > > time, it should be needing by serious number of users.
> > > And shouldn't be a big arthitectural problem for FB i think.
> > > We have ROW_COUNT context variable already and also counting
> effected
> > > rows at server side, why not put it in select list?
> >
> > ROW_COUNT works on the entire result set or number of
> > modified rows in a table. It has nothing to do with record
> > numbering.
>
> ouh!
> how can you fill ROW_COUNT datatype without counting result rows step
> by step? is it impossible to add it to row field list?
> are there megical something that i could't learn about software
> science? perhaps... you know we living inside a problematic meridian
> group, sorry. ;)

I don't follow your hippo argument, but I agree that it may be
possible with Firebird 2 to output an interim counter value, the
counter that after the operation completes is ROW_COUNT.

My questions about the usefulness remain. It encourages poor design,
increases the data size to be shipped across the LAN, slows the fetch
time, and is probably already available in the client query component.
Any guesses what the next question will be? How about 'I want to
update the 10th record returned by my last select, can this be done?'

In Firebird 1.5, ROW_COUNT always returns 0 for selects or any query
run using EXECUTE STATEMENT (FB1.5 release notes p22-23). It is a
method of checking how many records were effected by other DML statements.

Adam