At 09:04 PM 4/5/2002 +0100, Artur Anjos wrote:

>And that's the only way. FB does not have a counter of the number of rows
>anywhere.

And the reason it doesn't, is that there may be different numbers of
rows for different concurrent transactions. For a simple example,
take a table with 100 pre-existing, committed rows. You store 100 rows
that you haven't committed - they should show up in your count which
should be 150. If someone else also stored 100 rows without committing,
those rows should not show up in your count but not in his - he'll also
count 150 rows but they'll be different rows. If yet a third concurrent
transaction just deleted 50 of the old rows, her count will be 50 because
she won't see the new rows or the rows she deleted. If all three commit,
the next transaction will see 250 rows - before it starts changing
things.

The multi-generational thing makes this harder, of course, because
consistency requires that you continue not to see her changes (or its)
after she or it commit. So it's not just uncommitted data that can't
be counted but also committed but inappropriate data.



Regards,

Ann
www.ibphoenix.com
We have answers.