Oh please confirm this as a known bug or tell me if there's a known cause that I can pursue!!
One of our clients discovered that when doing a SELECT on a btree index on TWO values it returns more record keys than the sum of individual selects:
SELECT file WITH field "A" "B" returns 3084 records–WRONG
SELECT file WITH field "A" returns 372 records - CORRECT
SELECT file WITH field "B" returns 2219 records - CORRECT
SELECT file WITH field "A" AND WITH field "B" returns 4 records-WRONG
The correct number of records for the combined search is 2579, and the resulting list of 3084 records has some record keys listed twice. The field being indexed is multi-valued, and none of the records in question has any null values. 12 records have both values, doing the select using AND finds only 4 records. Although there are some records that have no value at all for this field, none of those records is affected by this SELECT.
We have a utility that checks for AREV delimiters in record keys and have ruled out that possibility. We have done a select using non-indexed symbolic fields to determine what the correct records are supposed to be, ruling out corrupted indexes.
I can recreate this on my AREV 2.03 system using a copy of their data volume (I cannot repeat it on my own data volume which is much smaller). I tested the criteria using BTREE.EXTRACT and BTREE.EXTRACT returns the correct records. I tested the SELECT statement using my AREV 2.12 and the select then returned the correct records.
Therefore, is this a known bug in AREV 2.03 that was fixed somewhere on the way to AREV 2.12? Is there a known way to work around this problem (especially as we cannot upgrade our clients to AREV 2.12)?
Thanks!
Maggie
]Oh please confirm this as a known bug or tell me if there's a known cause that I can pursue!!
As far as I know ARev 2.03 Select and Indexing processes are relatively bug free. Select problems cropped up in the beta versions of the Lightspeed project (I don't recall if that was 2.1x or 3.0x) which had major changes in the the SELECT engine but those were pretty much solved by the production releases.
]We have a utility that checks for AREV delimiters in record keys and have ruled out that possibility. We have done a select using non-indexed symbolic fields to determine what the correct records are supposed to be, ruling out corrupted indexes.
And the result on the non-indexed symbolics? The same number of hits or different? What happens if you use synonyms (F type descriptors with same field number, justification and length, different name)?
]I can recreate this on my AREV 2.03 system using a copy of their data volume (I cannot repeat it on my own data volume which is much smaller). I tested the criteria using BTREE.EXTRACT and BTREE.EXTRACT returns the correct records. I tested the SELECT statement using my AREV 2.12 and the select then returned the correct records.
Are you using a different copy of ARev with their data or a slimmed down clone of their system (Same SYSOBJ/VERBS, SYSPROG, AREV.EXE etc.)? If different, what happens when you remove the indexes and add them back on? Same with a clone? What happens if you reapply the v2.03 maintenance update and remove and rebuild the indexes (there have been several versions of this update, the distribution floppy version I have does not match the copy that was downloadable from CompuServe which doesn't match the version downloadable from here).
]Therefore, is this a known bug in AREV 2.03 that was fixed somewhere on the way to AREV 2.12? Is there a known way to work around this problem (especially as we cannot upgrade our clients to AREV 2.12)?
You said earlier the indexed fields were multivalued, are you taking into account that the select process will explode the multivalues?