Here's an update on this issue...
So I went into the code and added a FLUSH behind the TABLEUPDATEs and now he's getting "Error 1104 (Error reading file)" ...which is usually indicative of faults in the network connection for some reason. Client's Tech guy said he's replacing a Switch soon that appears to be faulty. Sounds to me like this could definitely be a culprit.
Again to recap: they've had Windows Server 16 for awhile and no problems until they updated the local clients to Windows 10. Also, the local A/V software has had exclusions programmed for the local VFP app folder, the network folder where the data resides, and the following extensions: DBF, CDX, FPT, DBC, DCX, DCT, TBK.
Your thoughts?
tia, --Mike
On 2017-06-08 13:57, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Heard from client's Tech guy. Apparently the Server 2016 has been in place for awhile. No problem when my app accessed from Windows 7 clients; problems only started with the introduction of the Windows 10 clients.
On 2017-06-06 17:18, Fred Taylor wrote:
Sounds like a caching issue.
Fred
On Tue, Jun 6, 2017 at 1:49 PM, <mbsoftwaresolutions@mbsoftwaresolutions.com
wrote:
VFP9SP2 app on Win10 clients; data on Windows Server 2016
Client showed me (via TV session) how adding records seems to show the new records in the local vfp view, then after saving, not showing them, then exiting and re-entering the app, the data is there. Now normally we'd say "well it must be a bug in the app" -- but this app has been rock solid and bug free with this basic add operation for 14+ years now. The only change in the environment is the new Server 2016.
Anyone having any issues with their VFP DBC tables residing on Windows Server 2016?
[excessive quoting removed by server]