>>Interesting. In your case it could be argued that the disconnections might have been causing the data/index corruptions.
>>
>>Was this related to your findings that things worked with Windows 8, but not with 8.1? Do you recall what the server policy was when you were running 8? Maybe something like:
>>
>>- Policy enabled, Windows 8 -> no problems
>>- Policy enabled, Windows 8.1 -> problems. If the policy is also present on clients, maybe client-side it's disabled by default in 8 and enabled by default in 8.1 (?)
>>- Policy disabled, Windows 8.1 -> no problems
>>
>
>
>The 8.0-8.1 fiasco is not related with SMB at all, when you map a network drive using policies, before 8.1 the default was to "update" which meant that if the drive letter was pointing to the right share/path then nothing would be done, but for windows 8.1 the default changed to "replace" which means that whatever your mapping was, it is replaced every time the OS checked its policies, this will close the connection and open it again, killing all foxpro applications in the process (it is better explained in one of the links I posted)
>
>The SMB issue/solution is independent of the client OS (well, no issue for SMB1 of course), we have XP/7/8/8.1 clients and by disabling the policy setting I mentioned before, we have no problems with any client (and as soon as we re-enable the policy then we get into the known SMB issues, we know for we set up and independent network for testing this a some of years ago, when we changed servers and the net admin forgot to disabled the setting and we started having issues, corruptions every day, even several times in the same day, a nightmare )
>
>>All this brings up another question. My understanding is the original SMB2 issue results in corrupted indexes, without any indication of network disconnection. If I recall correctly, Brandon Harker's repro code needs to run for a bit (i.e. server under load) before it manifests. Presumably it did so without disconnection errors (?) Also, it dates back to the early Vista days, I'm not sure the server policy existed back then or if it was enabled by default. So, I'm thinking the "original/classic" SMB index corruption issue is separate from what you've been dealing with.
>
>I never run Brando's code, but we have a piece of code that I wrote long long long time ago, that just moves data between tables and creates random records and shows the performance (how many bytes/seconds its moving/ how many records/seconds is creating and some other crap), not a very good program but it does its job. When we enabled said policy, it dies almost immediately after we start a second copy in a different machine, with the policy disabled, it runs not problem for days.
>
>But Al, we have hundreds of tables (thousands) some of them heavily used by multiple users and having hundreds of records added/updated per second (train information for example) so I think that if we had an SMB issue it would manifest, as it does when we enable digital signing. Or we are very very lucky....

Very interesting. Thanks for the recap of the 8.0 - 8.1 connection issue.

Regarding the server policy, and your test code, can you explain further how it "dies" when the policy is enabled? Does it experience disconnections, or do you get errors related to VFP data/index corruption?

Also, do you know if your server(s) have the Alaska Software registry changes implemented?