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