> >
> > Hi Mike
> > WHERE ckini >= DATE(2008,9,11)
is the recommended way to specify dates without depending on any national data formatting.
> >
> > -Anders
>
>
>
> In time tests that I have run over the years,
>
>
... WHERE MyDate = DATE(2008,9,11)
>
> runs slower than
>
>
... WHERE MyDate = {^2008/09/11}
>
> It's not going to matter all that much in the long run, but if you run it on a table of a few million records, there is a difference in speed. The second one always runs faster than the first. I think VFP is not quite "smart enough" to know that DATE(2008,9,11) is a constant, and so it calls the DATE() function 3 million times if it's processing a 3-million-record table (that has no index on the date field).
>
> Try the following:
>
>
for zz=1 to 20
> DateSpeedTest(1)
> DateSpeedTest(2)
> endfor
> function DateSpeedTest
> lparameters tnOpt
> lnSecs=seconds()
> for xx=1 to 3000000
> ldDate=iif(tnOpt=1,date(2008,9,11),{^2008/09/11})
> endfor
> ? padr(iif(tnOpt=1,"DATE()","{^yyyy/mm/dd}"),15,".")+str(seconds()-lnSecs,6,3)+" seconds"
>
> On my system, the {^yyyy/mm/dd} is almost twice as fast as the DATE().
>
> If you do a test program to create a 3-million-record cursor and do a SELECT...WHERE on it, the same thing will happen.
>
> So if I ever have a query that uses a date constant (which is infrequently to be honest), I always use the {^yyyy/mm/dd} syntax rather than DATE().
>
> --Brad
In that case DATE(y,m,d) it should be turned into a variable and the varible used in the query.
I prefer it to {^yyyy/mm/dd} because both { and ^ and } require some equilibristic finger movements on a Swedish keyboard.
This is a very international congregation of VFP users so American members shouldn't assume that MDY is a some sort of universal date standard, even if it's the default in VFP; far from it.
-Anders