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?