>>>
>>>John
>>
>>John, there is also this from Microsoft which offers a "fix" ...
https://support.microsoft.com/en-us/kb/2028965/en-us>>
>
>Out of curiosity;
>Did anybody tried this official solution ? What is the outcome/verdict ?
>
>I was originally very pi$$ed when I learn about existence of the problem, especially in combination with demise of VFP as tool...
>However my personal experience so far is that (for me at least) this is NO ISSUE not so ever!
>I am using
buffering and transactions throughout without exception (framework design) and so far (knock on wood) no issues!
>No registry hacks not so ever and yes with SMB2 and later enabled. Of course this is anecdotal evidence but it is what it is.
>
>To John;
>My take is that if application was properly done at first place, SMB2 bug might not necessarily affect it. (but cannot be 100% guaranteed though) Just like 'back in those days' ;-) when properly written apps could survive even in bad network/power supply conditions, whereas badly written apps could corrupt data even in perfect network/power supply conditions.
>(and some conveniently blaming those problems on VFP shortfalls {g} )
>
>Good thing about this is that _there is_ 'official' solution from M$ on this one.
>It can be useful 'argument' in usually useless discussions on VFP longevity and such... ;-)
The SMB2 issue is not a VFP only issue. It affects all non-client/server type databases operating over a network using SMB2. I agree that an official MS support page and solution is a good thing. It seems to manifest mainly under very heavy load and probably, as you say, somewhat dependent on how the app is coded. But what do I know - apparently I'm just a self-proclaimed expert.
.
In the End, we will remember not the words of our enemies, but the silence of our friends - Martin Luther King, Jr.