The correct solution is to turn off Windows SMB and the Opportunistic Locking, not to do what is suggested below. Re-writing your software to make it very slow is never a good idea. -- Mike Yearwood
Last year I was on-site at one of our clients. One of the users called me over. He had just converted an Order into an Invoice. The new Invoice header was displaying the correct amounts, but there were no Invoice lines at all (and our software was wanting to fix the 'errors' in the header totals, so that they matched the total lines - which was zero).
While I was looking at his screen, the woman in the adjacent desk called me over to show me an Invoice that she had just created from an Order. The new Invoice header matched the original Order, but she had several extra lines on it (and our software was wanting to add these into the Invoice totals). The lines on her new invoice were the ones, that had gone AWOL from the first user's new Invoice. If I recall correctly, we rebuilt all CDXs at that point, and the lines all magically appeared correctly on their respective invoices (and our software was happy with the header totals).
I'd never encountered anything like this before (in the nearly 20 years we had had them as a client) - it was really weird. All their workstations were running Windows 10 Home (yes, the guy who bought them didn't consult me). Their 'server' was another Windows 10 Home computer they had recently bought, which was pushed into a corner and optimized for 'background services'.
I turned off 'Disk Caching' on the 'server', thinking that Win 10 Home was not up to it (and modern disks have extra RAM to do their own caching - and might do this better than Microsoft). But this did not help.
I then loaned them a new high-spec computer that I had just bought for myself, which could dual-boot Windows 7 Pro or Windows 10 Pro, and set this up as their 'server'. Windows 10 Pro had the same problem as Win 10 Home. So I rebooted it into Windows 7 thinking that this would be OK, as they had been successfully running a Windows 7 'server' at another branch, for many years. But no, my Windows 7 Pro computer had the same issues, even with its disk cache turned off. So the issue was obviously with the Windows 10 Home client-computers themselves, not the server. We did some testing here, and found we could replicate the problem on Windows 10 Pro computers. Interestingly in our testing here, the problem did not occur when we put the data on a small Linux based NAS drive. However, we ran the same tests here again (after a number of Windows 10 updates), and the problem now even occurs when the data is on the NAS drive.
After much testing, we have discovered a work-around. We now leave the live data tables closed, and use cursors for all data-entry. When we want to populate a cursor, we open the live table, run the SQL SELECT, and then immediately close the live table again. Similarly, when we want to save data entry, we open the live table, run the SQL UPDATE or SQL INSERT (or APPEND / REPLACE in some old and complex bits of code that we don't want to completely re-write), and then close the table immediately. This seems to work quite robustly (and the extra overhead of opening and closing the tables is barely noticeable).
I hope that this is helpful for anyone who has users moving to Windows 10 computers.
We are already running on Windows 10 PC no problem if we
Disable Opportunistic Locking and SMB2.
( Topic last updated: 2017.08.15 11:25:02 AM )