Maybe I'm missing something. I don't see any problem with returning a
constraint violation error to session 2 to say that you cannot insert
because test1_dept table does not have the dept_id or dept_no that
test1_emp depends on. So whether session 1 commits or does a rollback
afterwards, it would not be a confusion anyway.
Norman Dunbar <Norman.Dunbar_at_lfs.co.uk> wrote in message news:<E2F6A70FE45242488C865C3BC1245DA7AAA2D8_at_lnewton.leeds.lfs.co.uk>...
> Morning,
>
> >> When a transaction has
> >> not committed yet, it means it's not real yet and not ready for other
> >> sessions to look at.
>
> So in your test case, that would imply that the table is still
> effectivel empty for the other session, in which case ....
>
> >> So returning an error in my view is more natural
> >> or intuitive.
>
> ... returning an error to say that the data session 2 is inseting
> conflicts with data that is not yet 'really' in the table could be
> misleading. Especially if session 1 subsequentl;y issues a rollback.
> What is session 2 going to find when he/she looks at the table to find
> out why they got an error ? Absolutely nothing there and so they will
> think something is broken.
>
> HTH
>
> Regards,
> Norman.
>
> ------------------------------------------------------------------------
> -----
> Norman Dunbar EMail: Norman.Dunbar_at_LFS.co.uk
> Database/Unix administrator Phone: 0113 289 6265
> Fax: 0113 289 3146
> Lynx Financial Systems Ltd. URL: http://www.Lynx-FS.com
> ------------------------------------------------------------------------
> -----
Received on Tue Jan 29 2002 - 09:12:45 CST
