Row lock level

Hi all, Could someone explain me how Ifx manage lock level? I'm working with an IDS 7.30 and suffering the next: I got a table with row lock level. It has a unique cluster index by two of its columns. I'm locking one row using a cursor for update. If I lock row number 001 I cannot access the others, and the engine show me this lock HDR+IX (what's I? Index?) but if I lock row number 020 I can access row 001 thru 019 and cannot the others. Any clue? Obnoxio tell me something funny please Thank all. Jorge Puente Hola, Podr'a alguien explicarme como gestiona Ifx. los niveles de bloqueo. Estoy trabajando con un IDS 7.30 y tengo el siguiente problema. Tengo una tabla con nivel de bloqueo a fila, tiene un indice 'nico y cluster por 2 columnas. Realizo el bloqueo con un coursor for update. Si bloqueo la fila 001 no puedo acceder al resto, (el bloqueo que me ense'a el motor es HDR+IX. I es de indice?) Pero si bloqueo la 20 puedo acceder de la 1 a la 19 pero no al resto. Alguna pista ? Gracias. Jorge Puente

Jorge Puente Beltran wrote: > > Hi all, > > Could someone explain me how Ifx manage lock level? I'm working with an > IDS 7.30 and suffering the next: > > I got a table with row lock level. It has a unique cluster index by two > of its columns. I´m locking one row using a cursor for update. If I lock row > number 001 I cannot access the others, and the engine show me this lock HDR+IX > (what's I? Index?) > but if I lock row number 020 I can access row 001 thru 019 and cannot the > others. The engine not only has to lock the row itself but all the index nodes that contain the row since any of them might need to be modified. I assume that this is causing you concurrency problems. If the cursor is holding the row it is to update only briefly then SET LOCK MODE TO WAIT nsecs in all the apps accessing that table so they will wait for the lock to be released. If you are holding the lock while a user peruses the row and decides whether to update it, stop now! Recode to FETCH the row WITHOUT the FOR UPDATE clause but including the ROWID, display and take input/updates, FETCH again by ROWID and compare either all non-key columns or some TIMESTAMP column to determine if the row has been modified while the user looked it over. If not update WHERE ROWID=... If modified, notify the user and redisplay the updated version for re-modification. It cannot hurt to SET LOCK MODE TO WAIT nsecs anyway so there are no spurious lock outs at the moment the row was updated. This will eliminate the concurrency issues altogether and is the prefered method. Art S. Kagel