Bob,

That's good news, of course!

But what seems odd is that you report that SET REFRESH would have done the trick save for its high overhead.

Since the Help is very explicit that SET REFRESH *ONLY* affects BROWSE, and since your original made no mention of BROWSE, this is puzzling to say the least.

Have we got another undocumented VFP "feature", or just some missing information from your side of the picture???

regards,
Jim N

>We've got a solution!
>
>Thanks to all who responded.
>
>The key was the REFRESHing of the data, but not the SET REFRESH itself.
>By SETing REFRESH to a lower number (default is 5 seconds) of ,say, 2
>seconds, our data could have been "not current" for up to 1 seconds - an
>improvement. Note, its only UP TO 1 seconds, and not necessarily 1
>second itself. The REFRESH will happen once each 1 seconds .. how long
>you have to wait depends on when you started looking during that 1
>seconds. You will recall that I experienced waits of 2 to 5 seconds.
>My 5 second upper limit turned out to be REFRESH's 5 second default.
>
>Because REFRESH works on ALL open tables, droping the time to 1 second
>could really tie up system resources - ALL tables being refreshed 5
>times as often! What we really want is a refresh on demand type
>function but only for the table we are dealing with. Christian Berrigan
>of Spartacus Development came up with the trick. It turns out that USE
> will force the local buffer for that table to be refreshed.
>
>The USE does take time ... about 2/100 of a second, but
>that's a lot better than waiting up to 5 seconds like we used to without
>it.
>
>
>User B's code NOW looks something like this
>
>
>use Food shared in 0
>set order to Vegetable
>
>do while .t.
> use Food order Vegetable shared && This is the magic!
> if seek("Turnip")
> ? "We found it at ", seconds()
> exit
> endif
>enddo
>
>
>Thanks again
>
>Bob