We are running an OI32 (ver 4.0.2) dedicated index server on a system using both OI and ARev user interfaces. If a user on an ARev 'front end' does a select on a perticular index that will take a long time, or that user cancels the select but then does nothing on that terminal, the index server sits at the locked index record and is inaccessible until that index is freed. The machine running the index server also then goes up to 100% CPU utilisation. Is there anything that can be set to ignore locked index records or is this a known problem ??

Regards,

Simon

This appears to be due to an ARev error. The issue with a long running selection is acceptable, the other isn't.

If in TCL, Select Table with column=??' and then Escape.

This leaves the !Table, Column*Root record locked. This lock is only cleared on logging out of ARev.

Any thoughts anyone ??

Simon

Your station locked it, so write a routine that unlocks it.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Not necessarily my station … if a user runs a select and then cancels it I wouldn't expect ARev to continue to hold the index record locked. We are looking at ways around this, but I would have thought that the index engine shouldn't just halt at this until something comes along and kicks the lock off.

Is this a known ARev bug at all with a patch ??

Simon

There is no patch that we are aware of.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Thanks.

Simon

There was a "bug" in Arev 3.0 (beta at least, it may have been fixed in the release version) that would not unlock these records on index re/builds.

Otherwise this is the first I've heard of this problem.

It definitely happens in Arev 3.1, it wasn't obvious until we put the OI indexer on it.

We've got round it as we have a replacement to the background indexing on normal workstations and that now checks for locks and clears them as necessary.

View this thread on the forum...