>First of all DTOC() doesn't guarantee chronological ordering with the default
>SET DATE AMERICAN.
That's obvious, and a given.
>That means indexes won't operate as expected.
It will operate
exactly as expected. It just won't be the order in which most people would want to have something indexed. There's a difference.
>Second, the value returned by of DTOC() is dependent on 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?
That's the part I was missing.
No. I've never had this happen. My applications have always been deployed within individual companies and those settings are global within their network.
>Ever have situations where customer wanted dates to be displayed in a format
>matching their locale, or in a specific format?
Yes. It doesn't affect the index. You call the function which converts it, which politely restores anything it may have temporarily altered in the environment.
>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?
No. The index would not have changed in my applications. It would've worked as it was originally created, and at all points forward.
It sounds to me like the warning should be more along the lines of:
If your application will use different locales, or if you are changing SET CENTURY or SET DATE settings manually, then avoid using DTOC(). Otherwise, DTOC(x,1) will always work just fine.This sounds like another one of those "m." issues where you must use "m." to be sure. But if you can be sure that in your particular environment these factors are not a factor ... then it is perfectly fine to use.
Regardless, in Visual FreePro I've overcome both failings / shortcomings in Visual FoxPro:
http://www.visual-freepro.org/wiki/index.php/VXB%2B%2B#t.Good.2C_m.Badhttp://www.visual-freepro.org/wiki/index.php/VXB%2B%2B#INDEX_ON_meta_data
