>>>My program has the following code
>>>
>>>datexo=LEFT(datx,2)+"/"+monato+"/20"+SUBSTR(datx,8,2)+" "+SUBSTR(datx,11,6)+":00"
>>>
>>>which results in a data like 28/10/2015 10:30:00 still in character format
>>>
>>>its then appended into a date time field
>>>
>>>This works fine as long as I run it from inside VFP on all machines
>>>
>>>But if I run it as a scheduled service or from Explorer on 1 machine the date time field is blank although the character format is the same 28/10/2015 10:30:00
>>>
>>>What is the problem?
>>
>>Here's my guess for why it works in the VFP IDE but not outside -- you've probably configured VFP IDE so that date is British (dd/mm/yy) format. VFP (both the IDE as well as the runtime) by default starts up in American format (mm/dd/yy) -- and settings in the IDE aren't duplicated in the separate runtime. This means that you'll need to add a "SET DATE BRITISH" explicitly in your code so that character format for date will be in mm/dd/yy format. However, as Tamar suggested, it's best to avoid any dependency on the locale-specific formats and use functions like DATE() and DATETIME().
>>
>>I did run into the date format sensitivity issue ages ago back in the PC/MS-DOS days in dBASE III+. To get around the problem, I ended up coding something like the following to construct date values (note: this code was only necessary because at the time there was no DATE() function available in the particular environment):
>>

>>* MKDATE.PRG
>>PARAMETERS nDy,nMo,nYr, dRet
>>PRIVATE dChk
>>
>>dRet = CTOD(" / / ")
>>dChk = CTOD("1/2/3")
>>DO CASE
>>    CASE MONTH(m.dChk)=1     && mm-??-??
>>        IF DAY(m.dChk)=2     && mm-dd-yy
>>            dRet = CTOD(ALLTRIM(STR(m.nMo))+"/"+ALLTRIM(STR(m.nDy))+"/"+ALLTRIM(STR(m.nYr)))
>>        ELSE                 && mm-yy-dd
>>            dRet = CTOD(ALLTRIM(STR(m.nMn))+"/"+ALLTRIM(STR(m.nYr))+"/"+ALLTRIM(STR(m.nDy)))
>>        ENDIF
>>    CASE DAY(m.dChk)=1       && dd-??-??
>>        IF MONTH(m.dChk)=2   && dd-mm-yy
>>            dRet = CTOD(ALLTRIM(STR(m.nDy))+"/"+ALLTRIM(STR(m.nMo))+"/"+ALLTRIM(STR(m.nYr)))
>>        ELSE                 && dd-yy-mm
>>            dRet = CTOD(ALLTRIM(STR(m.nDy))+"/"+ALLTRIM(STR(m.nYr))+"/"+ALLTRIM(STR(m.nMo)))
>>        ENDIF
>>    OTHERWISE                && yy-??-??
>>        IF MONTH(m.dChk)=2   && yy-mm-dd
>>            dRet = CTOD(ALLTRIM(STR(m.nYr))+"/"+ALLTRIM(STR(m.nMo))+"/" ALLTRIM(STR(m.nDy)))
>>        ELSE                 && yy-dd-mm
>>            dRet = CTOD(ALLTRIM(STR(m.nYr))+"/"+ALLTRIM(STR(m.nDy))+"/"+ALLTRIM(STR(m.nMo)))
>>        ENDIF
>>ENDCASE
>>

>>
>>Of course one could create date constructs in FoxPro using the curly-brace notation -- but unfortunately it is dependent on date format (unless you specify caret to denote strict format -- but that was introduced later in FoxPro language). I once demonstrated to the rest of the development staff the dangers date format sensitivity with a series of test programs. I had a several simple programs (it simply returns a date value specified as a date constant with curly-brace notation without using the strict date format) -- all of them were identical, except for date format configuration at the time they were compiled. I than called each of these individual modules from a calling program, then displayed the date values returned -- each program returned a different result (which was dependent on the date format effective at the time they were compiled). Surely you'd say that this is an "impossible" situation that should *never* occur in actual live code. Ah, but what if you've implemented some coding that effectively does a run-time compile? What if you've got code where you perform EVALUATE()?
>
>Thanks but fixed by Tamar Granor

But understand that Naoto has explained why you had the problem. In general, you should avoid any code that relies on knowing the date format. If you must depend on it, then you need to set it when you need it.

Tamar