>>>I am sure that you all have found this out by now, but in FPW 26 (and prob VFP too) under Windows 98 the date default is not MDY but DMY.
>>>
>>>If you do not have SET DATE AMERICAN or SET DATE MDY in your program, you could be getting a nasty surprise.
>>
>>Hi Joel,
>>
>>Not on my installation of Win 98 it wasn't. It is something, however, that is user configurable under the control panel's regional settings. I believe that this information may be available via an API call, but I'd have to check.
>
>My app does not have a set date in it. I tested it on 4 98 platforms and it is working on client site under 95. For some strange reason this results in the above error. I tested it also at the command prompt. In 98, on my systems, CMONTH(CTOD("10/01/98") gives "January". In 95 it gives "October". It has got to be some setting, but the fact that there is a consistant reproduceable symptom of a problem, I want to make people aware of. I guess the bottom line is to check your individual application, or if strange things start happening with dates, this provides a place to start looking. The Set Date MDY or AMERICAN corrected the situation without much fuss. The Docs (at least in FPW26) claim that the default format is MDY, but this is apparently system dependent.

Hi Joel,

I'd be interested in seeing what value SET('DATE') returned on those machines. AFAIK, FPW shouldn't be affected by a change to Win98, since it's a 16 bit app. Both Win95 and Win98 handle the clock differently than Win 3.1 did. The only possibility that I see here is that the regional settings on the machines are causing the calls to the thunking layer to return the date in the format specified there, thus confusing FPW. I tested this, however, and haven't been able to duplicate your results. So I don't think that's the problem either. I don't have any SET DATE statments in development, and under Win98, SET('DATE') returned "American" and your CMONTH() example returns "October".