Michel,

Glad you got back on this one. . . I mislead you earlier, as I seem to have a mental block about this issue which I can only guess was established in my early days of dBase, etc.

I have simply used DTOS ever since experiencing deep problems long ago with out-of-order date indices and (mis) concluded as I said earlier.

Jim N

>Dragan,
>
>{^2200.01.01} - What is this notation, what does it mean ?
>
>Michel Creppy.
>
>================== Your original message follows =============
>
>>>It would seem that in FoxPro 2.x the best way to index a table
>>>on a DATE field was to index on DTOS(Fieldname) as that
>>>created a character based index which proved to be much faster
>>>in operation than a date based index where, during comparison,
>>>dates had in any case to be converted internally to characters by FoxPro.
>>
>>It depends on your index expression. If it's a single field, you'd surely index on it as is. In case of date type fields, VFP would probably index on its Julian Day Number. If it's a DateTime, it already is a Julian Day Number (higher four bytes forming a long integer) with number of milliseconds since midnight (another long integer), and it will index probably by converting its both parts using BinToC() function, which should be pretty fast - it only adds a fixed value and swaps bytes around.
>>
>>If your date (or datetime) field is part of a compound key, DTOS() is the way to go, just to make sure it gets stored in the key expression as yyyymmdd (and be Y2K compliant, as it always was).
>>
>>BTW, there was a nice trick if one wanted to have a compound index on a character field plus a date field with the char part indexed ascending, and the date descending:
>>
>>index on char_field+tran({^2200.01.01}-datefield, "999999") to whateverTag
>>
>>Of course, if I wanted to use it today, I'd use
>>
>>index on char_field+BinToC({^2200.01.01}-datefield) to whateverTag
>>
>>The {^2200.01.01} notation is the new trick I learned here the other day :)