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?