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

All our tables are set to lock mode row and this still happened to us. In = our case it was with legacy Cobol programs navigating without using = indexes. We have brought the data into Informix and access via AcuCobol's = Acu4gl module, but I believe the principle would be the same for any = program not using dirty read. =20 >>> Nigel Gall <nigelg@ppsl.com> 10/02/98 05:37:45 >>> Tell me something, if you set your lock mode to row in the create table statement, do you still get this behaviour? At 05:42 PM 2/8/98 EDT, Peter Tashkoff wrote: > >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 > Best regards, Nigel +-------------------------------------------------------------+ |Name : Edmund Nigel Gall Tel: (868) 636 3153 | |Title : Information Systems Specialist Fax: (868) 679 3770 | |Company: Process Plant Services Limited |=20 |Address: Atlantic Avenue, Point Lisas Industrial Estate | | Point Lisas, Couva, Trinidad & Tobago, W.I. | +----- mailto:nigelg@ppsl.com ------ http://www.ppsl.com -----+