Hello!

I'm using FB1.5 RC4 SS Win32 and get very strange bug.

I have 2 tables:
table A (
ID integer primary key,
...
)

table B (
ID bigint primary key,
AID integer not null foreign key references A(ID),
Timetag timestamp not null,
Processed smallint not null default 0.
...
)

I have 2 application. Both are working in read commited record version
wait mode. Both are connecting to server via TCPIP. First one is
really simple - just download a datapackets (up to 1000 records) from
external source and make inserts (with Processed=0) in one transactions. After data has
been commited, this application send a message to second application
(automation object) and get a new datapacket from source. Same time,
second application opening new database connection and execute/commit stored
procedure. If there is a new data inserted by first application,
second apps has a new request on the queue and call/commit procedure again
and again. I.e. if external source has a lot of records, both
applications are working simultaneously after first packet has been
commited and new data packet could be commited at the middle of stored
proc execution time.

Stored procedure looks like:

create procedure ProcessData
as
begin
for
select ID, ..
from B
where Processed = 0 and ...
order by AID, TimeTag
into :ID ...
begin
...
update B set ..., Processed = 1 where ID = :ID;
end;
end;
Field B.AID has never been updating anywhere!

I have static external source database with about 100k records (i.e.
100 datapackets and about 70-80 ProcessData calls in the case, if both
applications works simultaneously).

In the case, if I run application 1 without processing routine
(without app2 calls) and then run ProcessData one time (after all data
is downloaded) everything works fine without any errors. But if
both application works simultaneously as described above, after some iterations (several
packets inserted and commited), I got "Foreign key violation on
constrant .. (B.AID)" inside FIRST (insert only) application.

Do you have any ideas why it happen?
Thank you,
Dmitri