Please forgive me if I ask about evident thing "as designed", but if
it is ancient unnoticed bug I want you to know about it. Anyway, if it
is mistake, it is rather widespread mistake and talk about it can be
useful for many developers.
I and some of developers whose opinions always were near to be
highest truth for others thought that IB SQL statement should "see"
only those records which existed when it was started regardless of
isolation level of transaction. I mean usual statement, not FOR SELECT
loop. But we made this test:

create table test (ID integer)

and in one application (app1) in read_commited transaction

C:=0; P:=0;
ibquery.sql.text:='Select count(*) from test'
While C<500000 Do
Begin
ibquery1.open;
C:=ibquery1.Fields[0].asinteger;
if C<>P then
begin
P:=C; RichEdit1.Lines.Add(IntToStr(P));
end;
ibquery1.Close;
end;

and in another application (app2)

j:=0; IBTransaction1.starttransaction;
For I:=1 to 600000 do
begin ibquery1.Params[0].asinteger:=I;
ibquery1.execsql;
inc(j); if j=30000 then
begin j:=0;
IBTransaction1.commit;
IBTransaction1.starttransaction;
end;
end;
IBTransaction1.commit;

started app1, then started app2, waiting

30000
60000
90000
...

but see:

5568
30000
60000
90000
116866
120000
134731

and so on

Thinking some time I understand what is it - some commited records
are placed on the pages which are already passed by current count(*)
execution, some not. But is it as designed? I can't remember on what
was based my inshurance about another behavior, and when one of us
asked this in bpi.bugdiscussions, Jeff Overcash, who is respected by
me as specialist regardless of all confrontations, answered in
the sense I had before this experiment.
We tested it on RC2 and IB 5.1 - the same behavior. So what is it -
widespread mistake or old unnoticed bug?

Thanks for your patience to read this long post.

Best regards, Alexander V.Nevsky.