If your versioning/update process is solid, go for installing local tables -
everything goes automatic with new version, no lags on startup at the cost of more ***visible*** client disc space.
If some error should happen, you can handle the tables much easier from outside the app to check things like missing columns or similar hickups.

You could fake it with a special cursoradapter for "often changing RO tables" if testing requirements/cost for new version is too hhigh in the process defined (but in reality YOU are then the one fingers are pointed to if one of the "only data refresh updates" borks). The app timer needs to fire a appwide special "checkROtables" method, which iterates over all CAs in the system (perhaps via .SetAll() and some dependencies created for RO-CAs) and there fires the RO-CA "ROupdate" which looks for the new base table or other needed gymnastics before calling .CursorRefresh or just deleting and creating bew local cursor.
You can also add a menu and/or button to fire the appwide special "checkROtables" method manually.
The client disk space is still needed (although invisible in \tempdir), more app code and delays created by "checkROtables", which needs to be made clear (if only by wait windows fired on each RO-CA "ROupdate" with the current # of all # RO-CA involved ;-)

.CursorDetach() might also offer further benefits - never went into enough detail on that angle myself ;-))

upd: read my own blurb several H later, of course wanted to prod the author ;-)
Another option might be to use offline views of the RO data: as soon as the server RO tables are changed,
signify a need to dropOffline() and a new CreateOffline()

//upd


>Thank you for your suggestions. In my case, to what I am thinking, the RO tables should works. Because these tables are for read-only. The only downside of storing the tables locally is updating/maintaining. Since the structure changes from time to time. I will have to think about this approach.
>
>>I would argue STRONGLY against using XML plus such a scheme.
>>Throwing XML into it will not help, but instead force much more processing time during which errors (this time from locking) might occur.
>>
>>"Get one of the free DB servers" is the correct answer to the technical problem for W or RW tables.
>>RO tables c/should be targeted to be installed client side, either updated with update process or on each run via small utility reading config file or comparing directory and copy file.
>>
>>If there is overwhelming exception to the above, add some code to internediate class of CA:
>>
>>- open server table
>>- (for the flakey network FLOCK including possible lock issues)
>>- after each cursorcreate, update/read or tableupdate, close server file
>>
>>dbf >> cursor is MUCH faster than XML
>>
>>>What I mean is if you have an XML on the server and the VFP code (e.g. XMLTOCURSOR()) converts it to a cursor (which is pretty much the same as DBF but is stored in local drive), would server SMB affect it?
>>>
>>>Because I do get the error messages similar to what Cyrus got "cannot read a file". And I thought that if I were to convert all DBF files that are stored on the server to XML, maybe it would eliminate the problem.
>>>
>>>>How do you convert XML into a DBF without opening a DBF?
>>>>
>>>>>PMFJI, do you know if SMB affects VFP converting XML file to a DBF? Or it is only when VFP application opens DBF/FTP files?