Btree Indexes Returning Bad Results (AREV Specific)
At 18 DEC 1997 04:05:31PM Jim Cross wrote:
Our customer is running Arev3.12 on a 3.12 novell Server with the
Arev NLM which was installed in May. About a week ago the btree index on the country field of a table began to return wrong results (i.e select table1 with country starting "A" returns 3 records that have "United States" in the field and some correct records.) We deleted the index and then rebuilt it per the knowledge base instructions. The index still returned the same results. If we simply remove the index the correct results are returned. We also tried creating a new table and then copied the data from one table to the new table using the copyrow command, but when we built the index on the new table the same bad results were returned. Right now we have the index off the field, but now a different field in the same table is starting to come up with bad results just like the other field. We have also removed the index on this field and now it returns the correct results. This table has over 9000 records in it and is very slow without the indexes. What can we do to fix the indexes and prevent any ot
her indexes from being corrupted.
At 19 DEC 1997 12:47AM Don Bakke wrote:
Jim,
Are your dictionary field lengths defined to be at least 1 or more characters longer that the longest possible data being stored in them?
Are you sure that there are no delimiters within your key ID's?
dbakke@srpcs.com
At 19 DEC 1997 02:16PM L. Woody Woodbury wrote:
I have similar problems with indexes on several different files. We are running Arev 2.12 on Novell 3.x and 4.x as well as some NT sites. I can removed and rebuild indexes on the files and in some cases the correct results are returned. In other cases, it makes no difference when the indexes are rebuilt. However, if I copy the record(s) in question with a delete option to a temporary file, update the indexes, copy the record(s) back and update the indexes again, the problem is corrected. This "solution" is not a viable one in that it only corrects the records in question, not any others in the file.
Any suggestions?
L. Woody Woodbury
Fulcrum InteTech
email WWoodbury@FulcrumIT.com
At 20 DEC 1997 02:42PM Aaron Kaplan wrote:
It could be one of 2 things. Either you have a delimiter in your key, which is throwing keylists out of whack or you do not have the key field set long enough. The display value defined in the dictionary needs to be about 6 characters longer than the maximum key value.
apk@sprezzatura.com
At 21 DEC 1997 07:35PM Tracy Kaltenbrun, ABC-Clio wrote:
Dear Jim,
We had a similar problem with one of our files.
Several indexes on the file returned incorrect data,
and it was the result of one or more records with
multivalued IDs. We don't know how the records got
created, the mv Ids were two of the normal ID format with
@VM between. As a matter of fact, occasionally we get
new records of this type and have to eliminate them.
The way we do it is to run a program that gets @ID for
each record in the file, determines if it contains @VM,
if it does, delete it.
(I am not at work, don't remember all the
code, but could provide it if needed.)
There is a message in this discussion group from
George Kent, 12/18/97, about Multi-value Keys. It
sounds like the same problem, and the suggested
fix was to list the records with multivalued keys,
access them via the list, and delete each record.
Does anyone know how these types of records get
created and how to avoid it?
Hope this helps. Thanks for any information.
Tracy