Another resurrection of this issue:

http://www.revelation.com/o4wtrs/oecgi3.exe/O4W_DOMINO_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&KEY=1C39929A29C183D585257300005795E0&KEY1=1C39929A29C183D585257300005795E0

I appreciate the responses that I have gotten, however, this problem continues to recur.

The 50-60K records queued for index update reference related to another table at another site, but with similar problems. I am basing that on the number of data items created in a specific process which was run prior to receiving the error.

In this case, I do not know how to check the number of records that need to be flushed (although this file is nowhere near as large or updated as often as the one with the 50K items to flush). Is this kept in a record in the ! file? If so, which one?

I understand that if the indexer has several items to flush, it will take time to process. But, in this case the index server is going gray and the task manager shows "Not Responding", so it looks to me like it is not trying to flush out the pending records, but it's just crashed. If it is balancing out the nodes, would it show this behavior?

Additionally, when trying to update the index manually through database manager, CPU ramps up to 100% and it just sits there saying "Updating Index". Attempt to rebuild the index results in same behavior. I suspect it's not doing anything, but instead waiting for the lock on the index file to be released, but it doesn't tell you that (would be nice if it gave us more messages about what it's doing or errors it encounters).

Since the last issue, I created a _NEW table (blank), removed indexing on the old table, dos-copied the dictionary files and the data files, then built indexes on the _NEW table. It has been running without issue since that point (mid-June).

There are no calls to INDEX_UPDATE in the code of the program that I am aware of. Update before query is not checked. So, the only machine that should be doing the processing is the indexer, which goes gray and task manager shows 'not responding' whenever it hits this file.

I am not sure if this is related, but the Event logs of the server show a LinearHash error from Friday. EventID=3000. Here is the description:

The description for Event ID ( 30000 ) in Source ( LinearHash ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: LHDeleteFile, 1102, 0, 0, ???..

Another from 7/19:

The description for Event ID ( 30000 ) in Source ( LinearHash ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: LHOpenSession, 1022, 0, 0, ???..

Another from 7/12; occurred several times:

The description for Event ID ( 30000 ) in Source ( LinearHash ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: LHReadNextKeyIdGroup, 1003, 1, 2, ???..

(anybody know how to set this up so we get the complete error messages?)

I was able to work-around this time by removing the indexed field that was 'stuck', but if anyone can shed any additional light or provide pointers, I would sincerely appreciate it.

TIA

Chip

We'll handle the easy one first.

1022 is a maximum number of users error.

1003 is a GFE, specifially an invalid frame header. Generally, this is a UD3 file trying to be accessed by the original LH drivers.

1102 is a resource in use error.

For the 1003, the service doesn't really put that much information in the error log, as you can see. File 1 should be REPOSIX, so you might want to check that. However, the LH service log and the LHX log use different file notions. You might be best to generate an LHSRVC log to locate the actual error.

For the 1102 log, this seems to indicate that the OS file is being access by a different process. This could be something bypassing the service, or some form of scan on the system, like a virus checker, file verifier or backup utility.

As for the general nature of the indexing error, the best idea I have is to take a copy of the system locally, if you can, and generate an OEPROFILE.LOG and LHx.LOG file while you update the offending index. Between these two files, we'll be able to determine all access to the file, what programs are running, how long they take and what records are being processed. Be warned, the profile log is huge, and it will take ages to run. After about 30 minutes, you can probably close out the system to examine the logs. That should have enough information for you.

The Sprezzatura Group

World leaders in all things RevSoft

Revelation Conference 2007, London - Wednesday 27th June Click here to register for the premier Revelation Software EMEA event of 2007

View this thread on the Works forum...