I forgot to mention - the trigger has
nothing to do with it. It's all down
to the index (id, timed) supporting
the primary key (id).
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )
____UK_______March 19th
____USA_(FL)_May 2nd
Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )
____USA_(CA, TX)_August
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
Jonathan Lewis wrote in message ...
>
>You've come across an interesting anomaly here
>that reproduces in 9.2.0.2
>
>If you support a primary key through an index
>that has extra columns, then it is not just an
>update to the primary key that can cause foreign
>key locking problems - an update to any of the
>extra columns in the index can ALSO cause
>foreign key problems.
>
>Since you are using sysdate in your testing, it
>is possible that the failure to reproduce came
>about because you were writing scripts to do
>the testing, and the update was occurring in the
>same second as the original PK insert - so the
>update became a no-change update, and did not
>have the same effect. You could try again, but
>inject a 1.5 second sleep with dbms_lock.sleep()
>
>
Received on Wed Jan 29 2003 - 08:48:49 CST
