Hello everyone; long time, no type!

In a file that has been been fine for five years, the BTREE index has become corrupted. It manifests itself in the following ways:

1) LIST PROSPECTS LASTNAME WITH LASTNAME ] 'A' works fine, as does 'B' and 'C'. However the 'D' list shows two 'C' entries!

2) LIST PROSPECTS LASTNAME by LASTNAME shows an occasional entry out of order (i.e. a "P" name).

I have deleted all indices and rebuilt; I have copied the file and reindexed the new file and the problem shows up on the new file; I have searched the file for FIELDCOUNT(@id) ] 1. The above manifestations work fine with the index removed.

No other files in this huge, stable system seem to be affected, so I'm not looking too hard for a network problem (Netware 4, Rev NLM 5.x, mixture of DOS, Win95,Win98 clients running Novell Client).

If anyone has any ideas where to look next, please respond. If you could also respond via email to mtankle@fortbsi.com I'd be most grateful.

Mike,

Check @ID and ID; are they still long enough to not be shorter than the longest data you're indexing? Are @ID and your BTREE field both MASTER FIELDS? (no, not Chesterfields!)

Sometimes, if we've rebuilt %FIELDS%, @ID or a field will lose it's MASTER setting, or we've let our data sneak past the length shown on @ID (or if it's a multi-part key, the sum of the lengths of the parts has grown past the length shown on @ID). Has anyone changed the justification any of the indexed fields or @ID or ID so that it doesn't match the data type?

If you've got a key like 1A*1 and another key in the file is 0B*99, which is it, Left or Right justified? (I always 0 fill my numeric counters so it doesn't matter) If your keys won't sort correctly, no matter what you do, then there's no way to fix the screwup except to change the format of the key or the data (whichever won't sort correctly). I ran across this a couple of days ago with another programmers indexing problems.

If all of that is ok, e-mail me and I'll send you my CHECK program that scans the entire file and it's structure to point out any problems that could interfere with any type of indexing.

BTW, if I recall what I read just a moment ago, you scanned the IDS for embedded control char(s); did you scan just for @FM or @VM or for all chars ] 128 or < 32?

Please let me know if any of this helped.

Larry

tardis@earthlink.net

Larry,

Sorry I didn't get back sooner; but I just got back on site totry your suggestions.

The @ID,ID dictionary entries have YES for MSTR. The longest ID is currently 6 digits and the display length is 10. We're talking about a single field key.

I would appreciate it if you could send along your CHECK program as you offered. I'm still checking for char(<33), but I'm not very hopeful.

Thanks again for your continued help.

Mike Tankle

Tankle Business Services, Inc.

mtankle@fortbsi.com

Mike,

As I mentioned in our private mail, I've been in the hospital, but I will clean up CHECK and get it to you by Friday.  It won't check the INDEXES yet; I have the code, I just haven't incorporated it.

It would also help GREATLY if all your IDs were like:

PATIENT file has field referring to PROVIDER, so the definition

in the PATIENT file is PROVIDER_ID, and any symbolic for PATIENT ID

from PROVIDER is PATIENT_ID.

BTW, I'm about to post a way to make sure symbolics get updated every time, just like XREFs; the key is stealing the code and modifying it on the fly when compiling the symbolic.

Later,

Larry

View this thread on the forum...