We often have on our dedicated indexer the following messages:

W602

The index row "FULL.DESC**KEY MOTOR MOUNT FOR KUE-KEN VSI IMPACT CRUSHER M

                                                                                         The indexed column "FULL.DESC"                                          in the table "STOCK.MASTER"                                                should be rebuilt.                                                      «   OK   »                             

We have NLM v1.5 installed on our Netware 4.11 server. All of the workstations running AREV 3.12 have Windows 95 and Netware client 32 v2.2 installed.

Also we tried to replace the machines for the indexer, but the problem did not do away.

What is the nature of this problem, how come index get corrupted? Is it really a problem? If so, how do we fix it or get rid of it?

Please advise.

I would strongly suspect that your value (KEY MOTOR MOUNT FOR KUE-KEN VSI …) that is to be indexed is too long for the BTREE index (that is what I'm assuming you are using). It's trying to use the the whole value to create the index on and can't handle it. You may want to look at changing the indexing from BTREE to Cross-Reference. Or you can cut down the value to a size that BTREE can handle (I don't know what its upper limit is).

Michael Slack

The error means that one of the index transaction nodes, the one listed, could not be read from the !file. It could be for one of any reasons, you might want to see what's in @file.error when the message displays (could be nothing, since the call to MSG might reset it).

Couldn't really tell you if it's actually not there or just returning back a failure. Could be a problem if there are some delimiters in the string, since somewhere along the line, it might end up truncating the long name.

[email protected]

Sprezzatura, Inc.

Ok, if the description is too long for the BTREE why am I able to rebuild the index for the whole table in DB Admin/Indexes/Update? Does indexer handle the indexing process in a different manner?

Sorry, I don't have a clue. All I can tell you is what we have ran accross. Your problem looks simular to times when we've had something that was just to big for BTREE to handle on a particular row. Were it was able to handle other rows with columns that were quiet large but apparently not large enough to put a wrench into BTREE's works.

Mike Slack

I can't really see how the key can be too long. While there is a theortical limit on the length of a key, it's 4,294,967,295 characters long, but you'll hit the 64K limit much before you reach this level.

There is an issue with BTREE.EXTRACT ($IDX_SETS actually) where if the legnth of the key is greater than the defined length of the key, there can be some retrieval issues. However, I don't really think that would come into play here.

Have you tried checking if this key really does exist or not? It could be that the index node has changed and the indexer is not seeing the changes. This would indicate some sort of caching issue. It could also be that the indexer is getting trapped in a lock loop and by the time it's freed, the key it was trying to read no longer exists.

[email protected]

Sprezzatura, Inc.

Well, I started to monitor error messages, and indeed all of the

"problem" records have lenth greater that 280.

View this thread on the forum...