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