>>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.