Re: Online bug? Tech Support clam it isn't
Dave Cook wrote:
>
> Any opinions on whether the following is a bug? Tech Support tell me it
> isn't as it's "just the way it works".
>
> Online 7.22 is the culprit
>
> When performing an update, a lock is placed on all rows scanned in the
> table, unless the update statement uses a unique index
>
> e.g. (very simple example)
>
> create table dave (col1 integer, col2 integer);
> create index i_dave on dave(col1);
> insert into dave values ( 1, 10 );
> insert into dave values ( 2, 20 );
> insert into dave values ( 3, 30 );
> insert into dave values ( 4, 40 );
> insert into dave values ( 5, 50 );> begin work;
> update dave set col2 = 100 where col1 = 1;>
> If I then (before committing) switch to another screen and update a
> completely different row in the table by doing the following:
>
> begin work;
> update dave
> set col2 = 1000 where col1 = 5
>
> I get the error:
> -244 Could not do physical order read to get next row
> -107 Record is locked
>
> If I create the index "i_dave" as unique I do not get the error.
>
> Thanks,
>
> --
> Dave Cook
It aint no bug, it depends on the lock mode of the table. If
you do not specify a lock mode at the table creation time, the
default of page mode is selected. In your example, since the
table is so small, chances are all of it is contained in a single
page. So, while updating the entire page is locked and the
second update is also trying to lock the page and hence the
contention.
Try to alter the table before the first update and set lock mode
to record and both of your updates will work fine.
Arun