odd results with scan search
Kenneth Brody
kenbrody at spamcop.net
Fri Nov 20 08:06:29 PST 2015
On 11/19/2015 3:08 PM, Nancy Palmquist via Filepro-list wrote:
> Bruce,
>
> On 11/19/2015 11:28 AM, Bruce Easton via Filepro-list wrote:
>> In a file where a field contains "Lyon" and I scan for records using
>> extended selection and ask for records containing (co) "yon", some results
>> are returned that include the records with name "Lyon". However, if I
>> search the same file on another field for "DPM" and some records exist
>> where that field contains "xxx/DPM", no results are returned. This is
>> with filepro 5.0.13.
Is it possible that the failing file's field has a right-justify edit, for
which "DPM" will pass the edit? (That would tell filePro that you want to
search for contains "<a bunch of spaces>DPM".)
> The important part of the answer is if you have index scan on or off, paired
> with that is if the field you are scanning is indexed and the field length
> is total in the index.
The "contains" search never triggers index assistance. (Think about it...
It can't use an index in such a case.)
> If the field is indexed, and you have scan/select ON (default behavior) then
> the search is done on the index not the real data. Try turning the index
> scan off by using -jn on the command line. Try it then.
>
> I can not remember if there is an environment variable to turn off index
> scan in the environment.
PFIXS=OFF, which is the default setting.
> If the index is built on less than the entire field or it is corrupt, that
> could explain your scanning issue.
An index built on a partial field won't be used for index assistance.
> Using Index scan can be much much faster but the index has to be reliable.
> I am not sure if the CONTAINS method might affect your index scan results
> somehow.
--
Kenneth Brody
More information about the Filepro-list
mailing list