Needs at least specs on backend queried - if you are querying vfp data, your (read) buffer assumptions are valid.

Even then it might be better to "level playing field" by repeating 1st query again to allow it to compare own "buffered" timing with timing of 2nd query, as vfp strength is in very smart buffering and your measurements should mirror situation occurring in real life, which probably re-uses already buffered data.

You might also look at sys(3092) with sys(3054) to get a better idea on vfp SQL - first one is something I was able to get implemented back then....

Also (I am in nit-picking now...) 1st run and kill vfp will leave .dbf data in disc cache, so 2nd gets boost by not needing to go though HD interface (SATA or NVMe for instance)


>Hi,
>
>How do you compare the speed between two SQL Select expressions?
>Typically I would do it like this:
>

>nStart = seconds()
>select * ......
>nEnd = seconds()
>nTime = nEnd - nStart
>

>
>What I am not sure is how do you account for the fact that the 1st SQL Selects creates some data buffer (I think it does but I am not sure). So, if the buffering assumption is correct, the 2nd SQL Select will have an advantage.
>Another approach, I think, is to do 1st SQL Select. Then, shut down VFP and on the next start to do 2nd SQL Select only.
>
>Any suggestions or comments?