>>>My statement here is also correct. The DTOC() index will work correctly until a date-related
>>>setting is changed. That is based upon years of use and personal testing in VFP9SP2.
>>>It may not sort properly without setting a specific date format, but it works properly.
>>
>>Would you prefer not to have the error message at all to duplicate the same behavior as
>>previous version, and have your program to silently fail or operate in an inconsistent manner?
>
>
>I don't see where it fails today. I have done a test where I created a table with two fields, a datetime and a date. I indexed on DTOC(tDatetime) and it worked. I was able to enter a BROWSE window and append blank (Ctrl+Y) and add or edit records. I started out with an empty table and had about 10 records by the time I was done. Changing the dates would reorder them in the list appropriately based on the date setting.
>
>I don't understand where this fails today outside of when the SET CENTURY or SET DATE settings are changed. But if in your app you do not change those conditions, or if you use the second parameter such as DTOC(tDatetime,1) ... then where does it fail?
>
>Naomi and Doug have said it is a feature now that it will not let you create the new index if the possibility exists of creating a variable length key, such as the output of a DTOC() function with century on/off.
>
>I don't see this behavior, so I've been asking what I'm missing. That is still my question: Where does it fail apart from a change in the setting while a particular flavor of index is in use? I haven't been able to duplicate the failure apart from changing the SET settings.

DTOC() doesn't guarantee chronological ordering with the default SET DATE AMERICAN -- so to guarantee that those indexes work properly you're SET DATE YMD (alternatively JAPAN or ANSI) and SET CENTURY ON (and it only gets messy when you realize that you've got to make sure these settings are correct in each data environment). The value returned by of DTOC() is sensitive to locale settings -- something you might not have complete control over. Ever run into situation where different PCs on the same network are configured with different locale settings? Ever have situations where customer wanted dates to be displayed in a format matching their locale, or in a specific format? And in the cases where you've got such a capability in your application, are you requiring your users to rebuild the indexes each time those settings are changed?