By "variable length keys" I meant that the expression used for index gives results that have different lengths for
different records. Since it's not at all obvious what VFP does behind the scenes, troubleshouting problems
generated by such indexes are a nightmare. Even if VFP creates all the keys with the same length for all records,
the length may be different from implementation to implementation and it may change when the reindexes are
rebuilt. This gives real variable length keys and the bugs are usually very difficult to reproduce.

The problems are somehow similar to the problems with SELECTs that generate field lengths depending on the
first row in the table. Still, in my experience, these problems are easier to find and fix.

Vlad

>In going through the thread yesterday, it turns out VFP doesn't really allow variable length key expressions. It derives the key length from the current record.
>
>So if the record pointer was on a record with a memo field value greater than 240 characters in length, it bombed. The same can be said if the current memo field was empty. But, if the length falls within the valid range then the index is created with the key length matching that record.
>
>As Ed pointed out, this can throw your sorting off if you have values greater in length than the generated key with similar starting characters.