Yes, it's because it sees the intermediate state (6,1) when it shouldn't (it processes each foreign key separately and does the cascade update which places it in an "invalid" state since the 1 key no longer exists). I believe the fixes I've been working on for deferred constraints will make this case work as well. On Wed, 18 Jul 2001 [EMAIL PROTECTED] wrote: > Bob Soeters ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description Two foreign keys in one table both referencing same > record in primary table gives error on update of primary table ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
