>Rick --
>
>Hey, thanks for your quick response!'
>
>You said .... " The only true system fix we've found is to disable the impacting cache options." Can you be more specific about how you did this? Which cache options?
>
>From my perspective, any solution, regardless of side effects, is preferable to no solution.

Hi James

I am running 2012r2 server for some time now (2+ years) and have no corruption of the type that is normally happening with smb2.
At first we switched one server only to try, and then as the time progressed (I was no longer in position to control what servers will be used due to takeover)
now ALL our servers are running on w2012r2

What I do have is minor index corruptions on a single dbf that gets over 1 000 000 records. It became almost standard and it is only happening
to that single table. I deal with it easily and regularly. But I had this problem on the same table since forever, long before smb2 even came into play..

At first I thought it was just some sort of temporary luck (and was very worried abt possible future failures!), but as time has gone by and nothing happened,
on multiple deployments on various servers, I started to believe that I might indeed have a 'winner' in this case... :-)

Now, (at risk of spooking my own systems, so knock on wood! )
I can say that THERE IS a way to safely run dbc/dbf as databases.
It is all just anecdotal evidence so far, as I have no way of running any conclusive tests, but I can only attribute this 'success' to the
throughout use of buffering (5) and transactions bands.

All access/write to ANY TABLE is ALWAYS done using buffering(5) and wrapped into transaction band/
So you either save all or revert all changes.

Always/always/always part is ensured by using (my own) framework which is handling and ensuring that all tables are always set to buffering 5
(multilocks on) and changes (dirty buffers) saved as part of transaction band. The same approach that is reducing table corruption to zero on unstable networks
(power shutdowns etc) is what I believe can protect you from SMB2 type corruption as well. Original design of framework was
done back in VFP6 times in the past century when having unstable networks and/or power supply was much more common then it is nowadays.
(techniques used are inspired by actual VFP help guide chapters on buffering and multi user access!)

How long it will all last before some future windows upgrade put a bullet in DBF usage head I do not know, but so far it all working quiet good.
(knock on wood again)

If I get a chance, I will try to produce one class and maybe put it here in downloads, in case someone can test it and see if they can actually
cause table corruption that is normally encountered with use of smb2.
Good source for writing your own classes for handling dbc/dbf based network apps is VFP help guide I mentioned before, as well as series of articles by
Andy Kramek that shed the light on these aspects of VFP programming. (see Foxite blogs by Andy Kramek)

HTH
Sergio