It may ( or may not :-) ) be, I just don't remember the details now. I have a tendency sometimes to do that, remember the main point and discard the details. I don't really like that ... probably just getting old. LOL :-)

>Bill,
>
>I have a similar recollection. I just don't think that Larry's rationale was correct.
>
>Cheers,
>
>JimN
>
>>I remember J. Booth addressing this issue and it was something along the lines Larry has indicated but I don't remember the specifics and my quick searches didn't turn up the threads. At any rate, I remember the bottom line being to not do trimming on indexes.
>>
>>Bill
>>
>>>Larry,
>>>
>>>Isn't this speculation?. . .I simply can't see it ACTUALLY working that way.
>>>
>>>I agree that that is what happens with a SQL-Select vs field lengths output but that is entirely different than keys/indexes.
>>>
>>>Regards,
>>>
>>>JimN
>>>
>>>>>I read that ALLTRIM on index fields can cause data corruption problems. Is this true? I have ALLTRIMs in many of my applications indexes. And some of the indexes use LTRIM RTRIM to accomplish the same thing. Is this better procedure: INDEX ON LTRIM(RTRIM(CODE_ID))+LTRIM(RTRIM(CODE))TAG ID_CODE
>>>>>
>>>>>Thanks
>>>>>
>>>>>Brenda
>>>>
>>>>Brenda,
>>>>Like Bill, I don't know of any corrption issues but the problem with using trims of any kind is with the how VFP builds its index keys. When creating an index VFP looks at the first record in the table (if one exists), applies the index expression (in this case alltrim) and calculates the length of the index key. If the field is C(10) and the value in record 1 is 'Foobar', the index key will be 6 characters in length. All subsequent values will be massaged to fit that constraint. If it's longer, it will be truncated.
>>>>
>>>>Example
>>>>If you have values of Foobar, Foobar1 and Foobar2 in your table, with Foobar occuring in the first record, you will never be able to seek on Foobar1 or Foobar2 because the value will be truncated in the index.
>>>>
>>>>HTH.