Re: solution has been found but till no explanation

There is at least one piece of literature that disagrees with this - I know because I wrote it. I don't know the evolution, so perhaps the rest is out of date, but (in the absence of the index on the child table and in Oracle 8.1) the child table is locked only if a parent row is deleted or a parent row has the referenced keys updated.

Alexander was 100% correct in his experiment - he showed that if you update a non-key column in the parent then the child table is not locked. But if you update a non-key column in the parent and a before-row trigger exists on the parent that MIGHT have to update the key column, then the child table is locked.

Taking this the one logical step further -

    the child is also NOT locked if the trigger has     the potential to update non-key columns in the     table.

[Quoted] [Quoted] I guess that Oracle has to decide the locking strategy based on the structure of the trigger rather than the actual values coming in.

--
Jonathan Lewis
Yet another Oracle-related web site:  http://www.jlcomp.demon.co.uk

Practical Oracle 8i:  Building Efficient Databases
Publishers:  Addison-Wesley

Reviews at: http://www.jlcomp.demon.co.uk/book_rev.html



Howard J. Rogers wrote in message <3aaf6f11$1_at_news.iprimus.com.au>...


>

>Any DML to a parent table (whether to the primary key or not) will cause


 the


>entire child table to be locked unless there is an index on the child


 field.


>And that's not discussable, since the literature is emphatic on the


 subject.


>