Have run into a serious problem and am hoping someone here can shed some light on the situation. Problems began yesterday with the following error message showing up on our dedicated indexer:

W613

The index for "LASTNAME.XREF" contains an internal error and cannot be accessed properly.

You may want to rebuild this index.

..Press any key to continue.

At end of the day made sure everyone was out of Arev, and attempted to remove the index. Received an error "FS466 - unable to delete… etc" during the attempt even though the removal appeared to go ok. Tried to create again, and again received a "FS466" error message although the index did appear to have been created. Attempted to rebuild and received yet another "FS466" message. Found that adding the command switch /p:256 to the LHIPXSER.NLM load was the only way to get around this error. However, the side effect was that Arev would lock the system upon exiting, and the attempt to rebuild the relational index would still not work (not to mention the performance hit). Multiple attempts at rebuilding would result in different error messages. Some examples:

'RTP5A' Line 2 B706 String Space Format Error

'MSG' Line 1 B114 Maximum number of variables exceeded.

'RTP50' Line 1 B114 Maximum number of variables exceeded.

???? Catalyst broke... (didn't write this one down so don't have the exact error)

Other strange things would happen has well. While trying to remove or define the relational index, system would lock. On those attempts where it could actually be ctrl-alt-del 'ed to close Arev, Arev would still think the relational file was locked upon re-entering and trying to access the index (no surprise here) - cold boot required to free up the file locks.

Some info:

Arev 2.11

NLM 1.5

Unlimited User Pack

Workstation:

Dell OptiPlex running Windows 95

Client 32 3.0.1.0 (WITHOUT sp1)

Attempted solutions (most of these tried on two different workstations - the system above and a Windows NT workstation):

Set up workstation according to specs given in tech. bulletin(s).

Properties for icon 4096, etc, etc.

Command line launched with /X /M4096

Frame type set to: Ethernet_II

Files set to 200

Have tried combinations of:

LH.NLM with /s:8

LHIPXSER /m:xxx where xxx has been different values

LHIPXSER /p:xxx where xxx has been different values ranging (down) from 470 512 (network packet size) - 42 (header) to 256.  Appears anything higher than 256 causes FS466 error messages when trying to do anything with indexes (even though day to day use is fine when this command line switch is not used).

LHIPXTSR.EXE /c:600

Have NOT removed all indexes on the file and tried a complete rebuild. Right now client info can still pulled from the file using two other indexed fields - if I remove these indexes and it is not the bang file causing the problems with the rebuild, there will be no way to pull client info. As one of my co-workers stated: "Better a little misery than a lot".

It has been suggested that I run through the file checking LASTNAME (the field whose cross ref index is toast) for a length exceeding say, 50 characters, or search the field for any high ascii characters which may be causing the rebuild to choke. Could something like this (length, high ascii) cause rebuild to die with a "variable exceeds maximum" message?

Should be noted that we never had a problem rebuilding indexes before the NLM install last November. This is the first time we have had to rebuild anything since that install. Could the NLM be the cause of our problem? Do not relish the idea of reverting back to before the NLM install to test this theory (we have also bumped to unlimited users since).

Guess my next plan of attack will be to wait until we have a backup Friday evening and then remove all the indexes from the file and attempt a rebuild.

Does anyone have any other suggestions? Why would the /p:256 need to be used when the network packet size is 512? Why the different errors while trying to rebuild ("string space", "maximum reached")?

Any help on this would be greatly appreciated.

Adrian

Normally when I get indexing errors of this type the easiest thing to do is clear the appropriate !file, remove indexing from the file, then add it back on.

Other errors could be due to file corruption from abending the ARev session.

You should download and apply the 2.12 update and patch file from this website.

Do as Warren suggested and remove all indexing from the file. Sometimes you will get error messages and if the indexing removal process breaks you to the debugger issue a G (go) command and continue. Once all indexing is removed verify the !index file was deleted. This normally takes place when the last index is removed from a file but I have known it to be left hanging. If so then delete it.

View this thread on the forum...