>>>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?
>>
>>I don't see how would that matter. SMB is about filesystem, so file control blocks, handles, locks at the raw bunch-of-bytes-on-disk level. File types don't even exist at that level, file types are for launching apps or for apps to decide what to do with them.
>
>Not so sure I follow your argument.

The filesystem doesn't care about file types, that's what I wanted to say. It doesn't distinguish between isam tables, indexes, .bak files, xml and whatnot - it just treats files as files. Open a file, get a handle. Lock a file, get a lock. Lock a portion of the file, get a lock on a block. Nothing else.

>SMB protocol could be viewed´/interpreted as a LAN based interface into the server file system. Server settings like Oplocks/Caching may throw a wrench into expected operations.

That's the problem of them windowses. The SMB stands for Samba, which is a unix protocol and does what you say, provide file access (and locking) through a network regardless of the OSes on either end. So a *x can talk with a windows can talk with a mac, as long as they stick to the protocol.

Of course, the Redmondlians never forgot the embrace-extend-kill strategy, so when they joined the SMB standard it had to be good for a while, but then they had to extend it (the oplocking, caching etc), allegedly to optimize it but the end result is that the database model with isam tables in a file sharing environment is practically dead on windowses. Though it would be interesting to test what happens with the faulty SMB2 and SMB3 if the file server is a linux box. Perhaps then it would just work, eh?