>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>As I go through my program, I see many places where I convert a string to date, using CTOD(), hard-coded with MM/DD/YYYY. But if the date is (for example), British ("DD/MM/YYYY") it won't work.
>>>>>>>>
>>>>>>>>How do you suggest I change all places that use CTOD() from hard-coded use of American date system to another?
>>>>>>>>
>>>>>>>>TIA
>>>>>>>
>>>>>>>If I had to do this task, I would write a program to scan through every PRG, VCX, SCX, FRX, wherever there was code, and identify all of the expressions with CTOD() and replace them with my_ctod(), and then add FUNCTION my_ctod to my utility.prg or main.prg, whatever is in the SET PROCEDURE TO path.
>>>>>>>
>>>>>>>The my_ctod() function would take the incoming form in the MM/DD/YYYY and you could translate it on-the-fly and return the value. Something like this (untested, off the top of my head):
>>>>>>>
>>>>>>>

* Note:  tcDate is MM/DD/YYYY
>>>>>>>FUNCTION my_ctod
>>>>>>>LPARAMETERS tcDate
>>>>>>>LOCAL lnMm, lnDd, lnYyyy
>>>>>>>
>>>>>>>    lnMm = INT(VAL(GETWORDNUM(tcDate, 1, "/")))
>>>>>>>    lnDd = INT(VAL(GETWORDNUM(tcDate, 2, "/")))
>>>>>>>    lnYyyy = INT(VAL(GETWORDNUM(tcDate, 3, "/")))
>>>>>>>
>>>>>>>    * Compute date in a standard form
>>>>>>>    RETURN DATE(lnYyyy + IIF(lnYyyy < 100, INT(YEAR(DATE()) / 1000) * 1000, 0), lnMm, lnDd)

>>>>>>>
>>>>>>>Something like that.
>>>>>>
>>>>>>Thank you. This sounds like a very good approach.
>>>>>
>>>>>I should point out that with GoFish, it shouldn't be very hard to simply change all those CTOD() calls to DATE() calls. You just write a little code to parse the CTOD() call to get the parameters and then create the corresponding DATE() call. Then you avoid all the workarounds.
>>>>>
>>>>>Tamar
>>>>
>>>>I prefer to change the CTOD() to DATE() manually because my entries are not consistent (currently) and I often hard-coded. When I go through them manually I make sure - and test - that it works for both American and Euro dates.
>>>
>>>You might be able to write the replacement function so it can figure out in most cases what to do and to just leave the other cases for manual work.
>>>
>>>Even if you don't want to do that, consider using GoFish to find them and using its Replace Line feature to let you handle them one-by-one. That should still speed things up.
>>>
>>>Tamar
>>
>>GoFish, I am sure, will find all cases. But I will be overwhelmed with so many. So, my plan - so far - is to go library (.VCX) by library. Open in the VFP IDE and get the source for all classes and methods. The Alt-F and look for all cases of CTOD(). I know this is slower but I think more stable. But maybe I will still do the GoFish approach.
>
>GoFish lets you see results for a single VCX if you want. My suggestion is to use it for all the easy parts (like replace CTOD(' / / /') with {}, and then handle only the hard ones manually. It gives you lots of flexibility.
>
>Tamar

I actually did ended up using GoFish to find all instances of the CTOD(). And went through them, one by one. It took about 4 hours. I have not yet changed the CTOD(" / / ") with {}. Probably will do it later today.
Thanks.