[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]] ==== Problem With Indexing (AREV Specific) ==== === At 06 AUG 1999 03:20:38PM Dale Walker wrote: === {{tag>"AREV Specific"}} 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 Dale_Walker@Integrityonline3.com ---- === At 07 AUG 1999 02:21PM Don Miller - C3 Inc. wrote: === 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. ---- === At 09 AUG 1999 11:15AM Dale Walker wrote: === 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 Dale_Walker@Integrityonline3.com ---- === At 09 AUG 1999 11:14PM akaplan@sprezzatura.com - [url=http://www.sprezzatura.com]Sprezzatura Group[/url] wrote: === I'll still bet it's a value mark in the key. akaplan@sprezzatura.com [url=http://www.sprezzatura.com]Sprezzatura Group[/url] [img]http://www.sprezzatura.com/zz.jpg[/img] ---- === At 10 AUG 1999 09:05AM Dale Walker wrote: === Precisely, Dale [[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=DD0E7175682225C1852567C5006A4295|View this thread on the forum...]]