>>>>>They are a response to issues introduced with SMB 2 in Windows Vista. At that time they first manifested as index corruption. I don't recall seeing any incidents of true "data loss" per se but a corrupt index can make it look like rows are missing, even if they are still present in a DBF.
>>
>>Are you certain corruption results directly in an error? I fear not finding/ loading some records without errors more, as this potentially "invalidates" correct RI logic by removing assumptions logic is built upon.
>
>Corruption *may* result in an error, the most common being "record is out of range" but failure to find rows that actually exist in the DBF because they aren't properly included in a corrupt CDX can be "silent" errors. These can lead to flawed decision making, with no easy way to know the decisions are flawed. And if discovered the trustworthiness of the app drops to zero.

Exactly. Those I fear more than a nice error msg...

>>>>Of course the danger of relying on registry patch is that they could get "undone" by things like installers as well as Windows Update. I vaguely recall this occurring with some regularity during the early days when SMB2 and SMB3 were being introduced (e.g. occurring whenever you ran Windows Update). Perhaps things may have "settled down" with SMB2/SMB3 enough that this probably won't occur -- at least until some major networking patch comes down the pipe....
>>>
>>>Good point. I haven't heard any anecdotes about this actually happening once those values have been set, but it could happen. Something like a Win10 Feature Update might do it, but we've gone through a lot of those since it was first released and again I haven't heard of those values being reset.
>>>
>>>One way to harden a VFP app against that possibility would be to check the local machine's registry at app start to see if those values are present and set as expected.
>>
>>Yes - but this is only the starting point: in my eyes it is difficult to propose even more coding for any special use case making remote .dbf borderline acceptable, as scalability will be reduced if done with a heavy hand, hightenining security one or two "9s" in the process.
>
>It's definitely getting to the point where the long-term cost to use a free RDBMS like PostgreSQL as a backend for a networked VFP app is lower than using native DBFs. A backend like that gives data more value, it's much easier to connect other applications to it.
>
>Native DBFs are still useful for single-user/standalone apps and utilities, datamunging etc where having low-overhead SQL is a plus. Although a case could be made that using other languages plus something like SQLite can compete in that space.

Nowadays I am even more careful - I will claim I can resolve certain tasks with vfp on local SSD. I have not checked speed differences to a task running inside server process in a language having speed lead over vfp p-code for non-data related loops and such. Node/V8 compiling JS running inside Postgres, Java inside Oracle or IL inside SQL server processes might have the edge now - vfp has received nothing similar to Hotspot or V8 JIT, it is still runing mostly the concept of middle nineties with some bad spots eliminated as soon as Calvin became aware of potential better solution.
Then there is vfp weakness of adressing arrays as "normal" vfp variables and only string-functional handling vs. memory element hopping in static languages, where you can adress the "array location" inside the string directly.