Re:Online bug? Tech Support clam it isn't

It is not a bug. You need the index to navigate the table. If you have no index each row = must be tested in a sequential read to see whether it meets the criteria = for update. The first thing that Online does is to place a lock on the = row, for the committed read. Since you are operating within a singleton = transaction this lock will not be released until your transaction is = committed. Not only is this 'Just the way it works', it is IMO, sound = design. It is a good idea to always navigate the table using indexes as sequential = reads for updates can also cause deadlocks between applications which are = trying to access totally unrelated rows. rgds Peter Tashkoff <tashkop@iname.com> Zespri International Limited. Standard Disclaimers apply All rights reserved, no party may use this document to vilify another Zespri New Zealand Kiwifruit, The Worlds Finest >>> Dave Cook <dave.cook@excelsis.co.uk> 7/02/98 06:10:29 >>> 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 );=20 insert into dave values ( 4, 40 ); insert into dave values ( 5, 50 );begin work; update dave set col2 =3D 100 where col1 =3D 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=20 set col2 =3D 1000 where col1 =3D 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, --=20 Dave Cook