>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()?