Re: Locked record

You can use the Key Level Locking instead, this will actually prevent Informix from locking the entire page. Regards, PS: Yes, this is a schema problem, try to reorganize your database , and specify the Key Level Locking. Mario Estrada ------------------------------------Reply Separator-------------------------- -----Original Message----- From: June Tong <june_t@hotmail.com> To: informix-list@iiug.org <informix-list@iiug.org> Date: Jueves 27 de Agosto de 1998 10:39 PM Subject: Re: Locked record >Richard Thomas wrote: > >> You could also try changing the LOCK MODE of the offending table to ROW, >> but I don't think that is your problem here. It looks to me like the >> index is being read by the 4GL, and crashing when it encounters a lock >> held by another user. >> >> > From: Marek Miloszewski >> > we have a problem with one of our application. Sometimes when somebody >> > is >> > inserting new record into one of the tables, other person has a >> > problem with >> > entering the application. Here is a message displayed: >> > >> > Program stopped at "function.4gl", line number 166. >> > SQL statement error number -244. >> > Could not do a physical-order read to fetch next row. >> > SYSTEM error number -107. >> > ISAM error: record is locked.>> > >> > The problem is that it does not happened continuously. One day yes, >> > another >> > not. Our application producer said this is problem with our Informix >> > configuration. But other programs work properly! I don't know were to >> > look >> > for error... > >It's not with your Informix configuration, it's with the database schema >and/or application design. > >The error "Could not do a physical-order read to fetch next row." indicates >that it is NOT using an index. It is doing a sequential scan of the table >(whatever table it is). You don't say enough about what the user is doing >when he "has a problem with entering the application." We need to know what >this means -- does he issue a query against some table, and if so, what is >the query? I see that you are using an outside application, therefore you >will probably have to ask them what is going on when the user tries to >"enter the application". > >My guess is that your table is missing an index which this query could use >to skip directly to your row. Without the index, the engine is forced to do >a sequential scan, and fails when it hits the row that the other user is >inserting. Since you are doing a sequential scan, it wouldn't matter >whether you have row-level or page-level locking on this table, it will fail >anyway. Once you get the index fixed, however, you may still find you will >need row-level locking to avoid locking conflicts. > >June >-- >june_t@hotmail.com >Lost in the wilds of Palo Alto, living on sushi > > >