Cheers,
Ann
> On Sep 6, 2019, at 8:24 AM, Mark Rotteveel <m...@lawinegevaar.nl> wrote:
>
>> On 6-9-2019 01:46, Carlos H. Cantu wrote:
>> I understand that there are other scenarios where the currently FK
>> behavior is correct and makes sense, for example, in the case of
>> avoiding deleting a master record with "commited but not visible
>> childs",
Yes. Unique, Primary Key, and Foreign Key constraints are handled in a special
omniscient mode to avoid concurrent, incompatible changes. Triggers and check
constraints operate in the mode of the user transaction.
>> but for the reported example, the currently behavior looks
>> incorrect, and for people with business logic implemented in triggers,
>> it may/will lead to incorrect results.
>
> I think you're right. You should only be able to insert records that
> reference records that are visible to your transaction. Given Tx2 started
> before Tx1 committed, the effects from Tx1 aren't visible to your
> transaction. Your insert in Tx2 should fail as the master record from Tx1
> doesn't exist from the perspective of Tx2.
Interesting. In the case of inserting a child, the master must be visible to
the transaction doing the insert. In the case of deleting a master, the
existence of a child - even if uncommitted must block the delete.
>
>> Does anyone knows if this behavior is following the Standard?
>
> I don't think this behaviour is correct in view of the standard, but I
> haven't looked it up.
>
No, this behavior is not standard compliant.
Good luck,
Ann
>
>
> Fireball https://lists.sourceforge.net/lists/listinfo/firebird-devel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
