Sorry, but only comments follow...

My first thought is wondering if this has been an issue for you previously, or if your main objective is just to "tighten" the code further as you migrate it.

As customary, the VFP documentation leaves a lot to the reader's imagination.

Nevertheless, I'd stack up your 'requirements' as follows:

a) The second parameter - nSeconds2 - of the SET REFRESH command seems most applicable to getting the changes to other workstations as soon as possible.
But I would be very wary of its -1 option to always read from disk for 2 reasons:
1) Help does not state when that happens (once, every record change?)
2) Who know what that might do to performance of the application.
My **guess** is that .5 seconds or 1 second should be helpful without impacting performance. Also, I doubt this does anything helpful if views are used.

b) Reading the Help for FLUSH... FORCE I would opt to:
1) always name a table when I used it;
2) keep it outside of transactions, using it right after the last END TRANSACTION of any nesting in such cases.
It seems fair to assume, but who knows for sure, that cache and/or buffers at the workstation are not invalidated by the FORCE issued at that workstation. Of course the same at other workstations would potentially be invalidated, but really only sooner than would otherwise have been the case.

c) SYS(1104) seems to have been 'improved' in VFP9. But to me it remains one of those options to be used only when prescribed to 'fix' a specific problem. Help is again too vague... How do we know if we are "executing commands that make extensive use of memory buffers"?... Does it include cursors too?... What impact does this have on operating system cached data?... What impact does this have when views are used?

The application I work with now uses SYS(1104), but that was as a workaround to a problem involving transactions and lost data or random errors.

I'm certainly glad that FORCE has been added to FLUSH, so at least now I have that option when I feel it is necessary.

I know, no help here. But maybe some things to think about. Basically, if it ain't broke, why change it?

good luck


>OK, my company are now moving all out existing codebase (VFP7) over to VFP9, so it seems pertinent that I revisit some of the code I use.
>
>I have trawled the UT, and Googled, reading many articles and comments about these commands, but there does not seem to be any 'real world' examples of where/how they should best be used.
>
>For example, consider a wrapper function around the TableUpdate function.
>
>

>Function MyTableUpdate (tvRows, tcAliasOrArea, taErrors)
>TableUpdate( tvRows, tcAliasOrArea, "taErrors")
>

>
>Would it be reasonable to add:
>

>Flush In (tcAliasOrArea) Force
>

>if one wished to confirm data is written to the drive as quickly as possible?
>(Assume an almost realtime networked system where another using is waiting for the data to be updated)
>
>
>What issues arise from having the data buffered? What if MyTableUpdate is called within a transaction?
>
>For the user waiting for the response, should the lookup routine make use of Sys(1104) ?
>
>Where do you guys & gals use these commands? Samples greatly appreciated
>
>
>Regards
>
>
>Malc