Hi Colin,

please don't ask why, because I can not give you the technical details, but using any of the trim functions in an index key, is a no-no. In earlier version of VFP such an index even give you an error that 'the index does not match the table' if your first record had few letters, and you appended a record with more letters. This does not happen in newer versions where the resulting index is not influenced by the trim functions, and in practice is redundant. Alltrim and ltrim are exceptions to the last sentence.

Another question is why use such an index when you can always control the data before it's put into the table? Or at lease, you should. :-)

>>>>LIKE clause is NOT rushmore optimizable (till VFP 9 if I remember corectly). Also If You want this clause to be optimazable the must change the WHERE condition to match the index. Can You post how the table is indexed?
>>>
>>>Borislav
>>>
>>>IF .NOT. EMPTY(consig) && If this variable contains Company name
>>> consig = upper(TRIM(consig))
>>> cWhere = cWhere + IIF(lAnd," AND ","") + "upper(trim(globalnew.Company)) LIKE '%"+consig+"%'" && Add ' before first & after second %
>>> lAnd = .t.
>>>ENDIF
>>>
>>>Index is upper(trim(company))
>>>
>>>Thanks
>>>
>>>Colin
>>
>>This type of INDEX may cause trouble. It is not a good idea to INDEX ON TRIM(). If You want the index to be left justified use
>>INDEX ON PADR(UPPER(ALLTRIM(Company)), 30, " " ) TAG ... where 30 is length of Field Company
>
>>
>>As I said LIKE clause is not Rushmore Oprimizable in VFP 8 and below. In VFP 9 it is (AFAIK).
>>
>>UPDATE: In VFP Like Clause is Rushmore Optimazaple ONLY in this Case
>>
>>upper(globalnew.Company) LIKE '"+consig+"%'"
>>
>>
>>w/o first %
>
>Borislav
>
>Never had a problem with a trim index - been using them for years - what sort of problem do you forsee?
>
>Thnks very much for all your help
>
>Colin