On Mittwoch, 16. Mai 2007, Adam wrote:

> lock conflict on no wait transaction
> violation of FOREIGN KEY constraint "FK_BAR" on table "FOO"

I have the same problem but I am still collecting info.
If you wouldn't have posted this I would probably have done
so in a few days - maybe I would even have waited for fb 2.0.2
Right now I will have to wait for the bug to happen again.

Adam, does dropping/readding the foreign key constraint fix it?


I currently suspect that a bug in firebird corrupts the
foreign key index, but I still have to verify that. However
it seems the problem goes away if I drop/readd the foreign
key constraint.

My preliminary findings in detail:

(2.0.1 windows SS and the latest official IB build)

in my case the violation exception message is wrong - the
referenced key definitively exists all the time and did so
since months.

I am quite sure that all I do is within the same transaction.
I do explicit StartTransaction and Commit.


1. this happens in a transaction importing data. Out of about 15000
records, I get 3 such errors. They are always the same records.

2. stopping/restarting the fbserver process does not help, even
when doing my transaction directly after restarting (no other
users)

3. after saving/restoring with gbak the problem went away
but came back 2 days later - errors with the same records.
This is what worries me most - is there something that
corrupts the data base? If so it must be a bug in firebird.
If it was hardware, it would not happen on the same records
again. gbak returned no error messages.

4. if I remove the foreign key constraint, I can do my transaction
successfully. Afterwards, I can successfully re-add the constraint.
My transaction never changes anything in the referenced table.

5. After doing point 4, the problem is gone - I can delete all
records from the updated table and do my importing transaction
again with no error messages.

--
Wolfgang