I have had various index corruption problems which have been difficult to resolve at customer sites. These have been almost impossible to pin down, as the files involved are different every time. The customer usually calls me after the user has rebooted to clear the problem!

Anyway, so I set up a test network and found the following:-

If a PC is set to be a dedicated indexer using SET_IDXSVR, and another PC locks row 0 in one of the bang files, then the indexing PC freezes. Windows messages are no longer processed, and this is when my darling users would reboot. As soon as the lock on row 0 is released, the indexer springs back into life. This occurs with ALL of the combinations of client and server that I have tried.

So my question is this:-

Is it possible to get the indexer to ignore indexes, which are locked, rather than waiting for the lock to be released? Also is it possible to change the indexer so that it doesn't freeze Windows? (Cam?)

Ashley,

I will forward your message to our Q/A group. It looks like there is enough information there to reproduce the problem. What I was not sure of when reading your message was this: Do the computers end up locking each other up, or does the client eventually release that lock thus allowing the index server to continue?

Cameron Purdy

Revelation Software

The client PC which has locked row 0 of the bang file usually releases the lock quickly, and then the indexing proceeds. Sometimes the user Alt-Tab's away to another application, or reboots before the lock is released. From then on whenever any PC does background indexing, the PC freezes.

Ashley-

We have reproduced your scenario when record "0" of the bang file has transactions to be flushed and another workstation locks record "0" before the indexer has flushed the transactions. As soon as the locks are released, the indexer continues on as normal.

Does your application ever explicitly lock record "0", or is the problem occuring due to our own record locking procedures as a result of a write to the !file of transactions needing to be flushed?

In our test, we made explicit calls to lock the record.

-Tracy Revelation

Our application does not explicitly lock row 0 of the bang file. The locks seem to be coming from our using update_index(,,'') within

event handlers to flush transactions.

My concern is mainly with the engine's handling of a deadlock. I think that it is not appropriate to lock up the PC completly, whenever it encounters one of these orpaned locks.

View this thread on the forum...