set a variable for the date at the beginning of the script. Then use the variable instead of the date constants in the script itself.
Set Variable [ $date ; Get(CurrentDate) ] //Manually available to set and test as an old date
If [ $date > "12/1/2016" ]
If [ Get(CurrentDate) > "12/1/2016" ]
You can also use the script debugger and data viewer to alter variables and pause the script to review results.
Mike, your basic idea is sound, but you are getting a bit sloppy in the script details.
$date > "12/1/2016"
isn't likely to be workable in actual code. I know it's just to show some "date senstive code", but you'd really want to use:
$Date > GetasDate ( "12/1/2016" )
or use the date function instead of a date in quotes--which evaluates as text, not a date unless converted with the getasdate function.
Thanks for the suggestions. I was also thinking along the lines of using a variable in my case using a global $$Date in a startup script. The method suggested works well when working on a small number of scripts and calcs.
However, when it comes to working on larger systems with multiple date based dependencies scattered across many tables and scripts. Replacing every get(CurrentDate) and get(CurrentTimeStamp) with a variable becomes time consuming and possibly error prone. Additionally ExecuteSQL needs to be taken into account especially if you are using commands such as CURDATE or CURRENT_DATE which use the system time.
I was hoping, as it appears rather naively, there was some kind of development utility available which emulates the system clock for development environments such as FileMaker enabling the developer to change date and time at will as well as run at high speed (x5 or x10) to test date/time dependent script triggers.
1 of 1 people found this helpful
Wouldn't you want it to be:
$date > Date ( 12 ; 1 ; 2016 )
Localization. So much fun.
Yes, jbante! that's exactly what is needed. no confusion what is month & day (regardless of where you are).