>I recently spent several frustrating hours debugging a problem which had arisen on our home grown proxy server where requests were instantaneously timing out. The cause of the problem was that successive calls to SECO() in FP26DOS returned values which in some cases were smaller than previous ones. The differences were small (less than .05 seconds) but I just can't figure out how FoxPro apparently thinks that time runs backwards!
>To prove to myself and my colleagues that I wasn't hallucinating I recreated a simple test program:
>
>clear
>for j=1 to 100
> ts=seco()
> do while .t.
> mtimenow=seco()
> if mtimenow>ts+3
> *3 seconds - no response - time out
> mpsreturn='timeout'
> exit
> endif
> if mtimenow mpsreturn='SECO() time error'
> ? mpsreturn,ts,mtimenow
> exit
> endif
> enddo
>endfor
>
>
>The results show that the behaviour is consistent - at least on my machine and several others here.
>
>Has anyone else experienced this?
>BTW the fix in the end was simple (if not elegant): I introduced a half second wait between the first call to SECO() and the second - which is really weird because now to detect a time out I have to slow things down!!!
Interesting... if you could bottle this and sell it to busy people, you'd get rich!
According to the docs for VFP5, SECONDS() has a resolution of 1 msec (10 msec under Windows NT). What is your OS? Maybe hardware abstraction is causing rounding errors.
You could try SYS(2) - which apparently rounds to the second, but which might be OK if your timeout is for multiple seconds.
Regards. Al
"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
Neither a despot, nor a doormat, be
Every app wants to be a database app when it grows up