>> - http://docs.rinet.ru/InforSmes/ch15/ch15.htm ( For an index, three
>> more locks are necessary--one lock for the accessed row, one for the row
>> before the accessed row, and one for the row after the accessed row)
>>
>
> Which version of IDS does this refer to?
>
> In any event, I never realised I was this lucky before. <preen> Maybe I'll
> enter the Lottery this weekend.
>
I use IDS 10.0 on Windows.
Here is statement sequention to demonstrate my problem:

Thread1:
UPDATE TABLE table1 SET col1=10 WHERE col2=15;
..... further processing for 10 minutes....


Thread2:
SELECT * FROM TABLE table1 WHERE col2=20;
(locked until thread1 finished).


There is index on col1 and col2.

Lukas

Lukas, if the below fails then I still think you are using page level
rather than row level locking


> I use IDS 10.0 on Windows.
> Here is statement sequention to demonstrate my problem:
>
> Thread1:
> UPDATE TABLE table1 SET col1=10 WHERE col2=15;
> .... further processing for 10 minutes....
>
>
> Thread2:
> SELECT * FROM TABLE table1 WHERE col2=20;
> (locked until thread1 finished).
>

scottishpoet wrote:

>Lukas, if the below fails then I still think you are using page level
>rather than row level locking
>
>
Not at all:

The number of rows in the table is small enough to cause the database
server to perform a sequential scan, and an index scan on a table with
lock mode configured to row.

It's my fault :-(
If I looked at access plan I could resolve this problem myself.
Informix gave me a good lection of database implementation.

Lukas