AREV 2.12. Application has been running for 9 years w/o problem. 5 B-Tree indexes on a Master file. One index is used as a direct lookup alias (it is a key in a foreign file and is used to retrieve records that way). The data is Alphanumeric but right justified. Two days ago, the B-Tree lookup started returning incorrect records for each lookup. Removed All indexes and rebuilt. All the other indexes are used for sorting except the problem one. Each index returns the file record count +2 (+1 I would understand – the

%RECORDS element). The sorts are fine but the same lookup is wrong but returns the SAME incorrect data. Made a backup of the file and cleared the original after removing indexes. Copied the backup record-by-record to the master. Re-indexed only the problem field. Lookup is still in error and returns exactly the same error records as before.

Anybody have an idea .. very bizarre to me. The network hasn't changed at all and the error repeats on several workstations so I don't think Novell is to blame.

TIA

Don Miller

C3 Inc.

Don,

We've recently seen some similar behaviour in one Australian site (using NT/Citrix). Have you checked for the obvious delimiters in keys?

For the record we were getting something like a "one btree node away" response - select clients with client_code 'FAIR]' returned client codes starting with 'EV'….we still are investigating this with the client… the files were partially trashed after faulty spreadsheet imports…reindexing didn't help.

Perhaps the same problem? Client on NT using NT service/Terminal server.

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

I'm aware of the Citrix / Terminal Servier issue, but this site is far too primative for that. Netware 4.x, Windows 3.1x, Win 95 versions 1 and OSR2, Win 98, & SE, 2 Win2k, 1 XP. Total 54 users on the lan. Won't buy the NLM. Using the NPP, though. I had to give it to them in order to keep my support nightmare in check. All desktops checked for write-behind, etc. No GFE's in the last 5 years, if you can believe that. Crappy data entry practice, though so your thought about delims in keys might be on target. A scan of the database didn't reveal anything obvoius, but I have a routine to scan keys for delims, so I'll upload it and test it there.

Very strange, though. I think you might be correct about a node offset issue since the improper key is EARLIER in the collating sequence then the desired record. They are all numeric (which I can't help, but don't like).

Thanks

Don

Just closing the loop on this topic. There was indeed a key to the table in question that had 5 values, separated by @VM's. It turned out that, after considerable probing, that one of the users indeed pasted a MV field into a key. Since the width of the key field was 7 characters and the first element before the @VM was 9 characters, it wasn't easy to spot it. Once repaired, the indexes are just fine.

Don M.

View this thread on the forum...