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.