Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
SET REFRESH
Determines how often data shared on a multi-user system is refreshed within a BROWSE and how often local data caches are refreshed from the server.
Usage
SET REFRESH TO nRefreshDisplay [, nRefreshBuffers ]
nRefreshDisplay = SET( "REFRESH" )
nRefreshBuffers = SET( "REFRESH",1 )
|
Parameter |
Value |
Meaning |
|
nRefreshDisplay |
0 |
The local engine does not check for changes made to the displayed data. |
|
Integer |
The local display is refreshed every nRefreshDisplay seconds. |
|
|
nRefreshBuffers |
0 |
Local data buffers are not refreshed. |
|
Integer |
Local data buffers are refreshed every nRefreshBuffers seconds. |
|
|
Omitted |
If nRefreshDisplay is set to anything other than 0, nRefreshBuffers is set to the same setting as nRefreshDisplay. If nRefreshDisplay is set to 0, nRefreshBuffers defaults to 5. |
A BROWSE shows a number of records on the screen at any one time, but other users might be changing those records as you watch. If REFRESH is left at its default state of 0,5, these changes are never displayed. For table fields displayed with other controls, you must lock a record to be sure the fields display the actual values stored on disk, but REFRESH can “read through locks” to show you the most up-to-date information available while within a BROWSE.
We generally feel that BROWSEs should not be used in applications; instead, they should be replaced by the far more controllable Grid. See “Commands Never to Use” for more details. Grids don’t seem to be affected by the setting of REFRESH, requiring either that the row receive the focus, the form’s Activate event occur, or the form’s Refresh method be called in order for data to be properly displayed.
The second parameter is less well documented. This parameter supposedly determines how often the locally cached data buffers should be updated with new data. Don’t ever set this parameter to zero, or you won’t see changes made to records displayed on screen until the records are locked.
It seems to us that the default setting of 5 seconds should beat the server to death with so many requests to update data that the entire system would come crashing down, but that hasn’t been our experience. On very large systems or WANs where network bandwidth is a precious commodity, we recommend you try raising the refresh level by doubling it and checking the performance change to the network and application. Ten, 20 or even 40 seconds between updates might not make that much difference in the appearance of your application, but could significantly affect other network performance criteria. As always, your mileage may vary; test your application under your environment to be sure of optimal performance.
Example
SET REFRESH TO 30