>>>A bit of recap for lurkers:
>>
>>And one observation / experience;
>>
>>Ever since SMB2 issue popped up into public attentio,n I was requesting network guys to disable it for any new server/installation.
>>
>>However in one instance this was NOT done so SMB2 remained in operation and remained so for very long time.
>>I realised that SMB2 was in operation for over a year (which caused fumes/flames coming out of mu nose)
>>So finally we disabled SMB2 and everything went on as usual.
>>
>>What I am trying to point out is observation/realization that; There was NO corruption not so ever for over a year!
>>And we are talking about app that actually uses shared VFP tables kept on server.
>>
>>Data access scenario I use is to have ALL tables buffered at ALL TIMES (optimistic 5) and every time anything is written into
>>any VFP database/table, it is always done inside beg tran/end tran transaction wrapper.
>>(Built in functionality universally applied)
>>Server in case was WS 2008 SP1,
>>
>>What I am wandering now (and question to SMB2 issue experts) is
>>Was I just lucky SOB ? Or, does applying buffering/transactions (or version of server) make any difference in this respect ?
>>
>>I hereby DO NOT advise against or for using SMB2, I am just stating observation / experience.
>
>A while back Brandon Harker posted some repro code here. I set up a test between a couple of Win7 computers, ran it for a while but the error did not show up.
>
>I seem to recall someone saying the test has to be run for some time, under considerable load for the problem to manifest.

Kind of hard to test isn't it. For 'considerable load' it has to be real production system. This installation was for not more then 10 users so I can't say it was
heavy load. The one that has relatively heavy load (40-50 users) I am not willing to put to this kind of tests.