One very general point: Using DBFs you think you get a live view of all data, but the network still is the network, so access to data in a file that's not local can still be tricky and lagging. Some mechanisms like opportunistic locking, when they fail, mainly, and they still do, let you think you see data that's not actually in the file, but only in a local cache, which is outdated in comparison to what's really in the file.
You have one main mechanism in VFP to access what is in a networked DBF: SQL queries. By definition and by default and by non-changable, non-avoidable default the SQL engine of VFP, all versions of it, too, do open up a dbf file for a query, and that highers the chance to read from the actual DBF file and not just from some cache that should represent the file. There still are caching mechanisms of Windows and of VFP that could mean you don't get at the actual file data, but it's by far the best way you have. That's another reason to use SQL.
You could try to mimic the SQL behavior by closing and reopening a DBF file yourself, the SL engine will also just use a dbf again in an unused workarea, so that will have the same effect. Anyway, that means that using a dbf and binding controls to it in a networked application always leaves you without full control about what you really see in your workareas, as network caching mechanisms can fail and are not fully in your hand.
Theoretically using a DBF in a workarea should give you an automatically updating view of the data in the DBF, but in the worst case it doesn't. Not only because you don't see the locally buffered changes, that's by design and wanted, but even after the commit by TABLEUPDATE(), you might not see those changes, as you reported yourself in your older thread.
Chriss