Anyone has idea why Firebird update and delete foreign key rule, work in a inverse logical?
When you changes some data and it is a FK, the Firebird behavior :
When my guess that correct behavior would be:
This a big problem when you try to replicate the data to another database in runtime.
It is the delete on master that causes the cascading delete. On an implementation level this is handled by a system trigger on the table, therefor the delete on the master has to happen first, and the delete from details is the result of that.
I don't know how you are replicating the data, but you might want to check if you are using BEFORE or AFTER triggers to do this (however I don't know if changing BEFORE to AFTER would change firing order to detail-master).
For more detailed information on implementation and limitation, you might want to post a question on the firebird-devel mailinglist. There are people following that list who have also built replication software, and the core Firebird developers might provide more detailed info.
