Problem with indexing.

We upgraded AREV 2.13 to 3.12 via 3.03. We are using Windows NT (Service Pack 5) on a Novell 4.1x network. Same occurs on Windows2000 server.

Our Human Resources file key field is the Employees SS# (9 characters as if this made any difference). We are using Name_xref as the index.

the Option command is B EMPLOYEE*NAME_XREF*NAME,SSN*KEYS in the Key prompt (SSN)

The primary symptom was that there were several individuals who would be listed twice with the same SSN by using a List command. For Example:

LIST EMPLOYEE WITH NAME SSN ID-SUPP

The Report would summarize with two rows found…

Thinking that this was an indexing problem, After backing up the files, I rebuilt the EMPLOYEE file which resulted in the following problem:

At the data entry window, I would press f2 and enter the name jones and then press f9. No Jones. But Someone completely different but the name would have the same first letter in this case J (fictional name) but the result would be the same if I looked up someone with the letter D or L or whatever.

I then removed the indexing - resulting in the removal of the !file. Then reindexed the file. Same result. I then did it the hard way. Then I rebuilt the index file using the menu structure. Same result.

We reviewed several topics on the search on this website and tried them but alas to no avail. Is there something That I am missing here?

Dale Walker

[email protected]

Posted this to you earlier - blank topic

First the obvious things:

Make sure that the EMS is set to 4096 in the properties of the Windows

Shortcut and that XMS is set to None and that the Uses HMA is NOT

checked. If your machine is not configured for EMS support then that may

cause problems with large numbers of keys.

Now for the AREV issues:

1. Do you have a Quickdex/Rightdex on the table. If so, it may be

corrputed.

2. If you turn off the Btree on the symbolic.Xref and then list the

table using the XREF field, do you get correctly parsed elements? If you

are using a name, you should see first, middle, last, etc. If you don't,

then the BTree will be FUBAR. If you do see the correct stuff then the

index should work properly. I don't have any experience with Windoze

2000, so I can't speak to it. No problems in Win95/98 or NT, though,

including Citrix and Microsoft Terminal Server variants.

Don Miller

C3 Inc.

Solved the problem. We found that there were two rows with the key field having the following format SSN²SSN with no data. We found this by exporting the table into a .txt file (all fields included) and imported it into a excel worksheet. The column for SSN had the above information for two rows.

I created a clean table tablename_new and copied the dictionary from the EMPLOYEE file with the (o)verwrite option.

I then verified that there was no junk in the _new table by going into dump and insured that I could not pageup or pagedown, etc.

I then wrote a small routine that selected the records from EMPLOYEE and checked for data. If data was present, I then wrote to the @id in the _NEW using WRITE.

I then made sure no one was in AREV and then renamed the original to "_OLD" and renamed the "_new" to the original filename. Reinitalized the indexing by removing it and restarting the indexing.

And it works.

Dale

[email protected]

I'll still bet it's a value mark in the key.

[email protected]

Sprezzatura Group

Precisely,

Dale

View this thread on the forum...