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?
tia, --Mike
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?
tia, --Mike
[excessive quoting removed by server]
On 2017-06-06 17:18, Fred Taylor wrote:
Sounds like a caching issue.
My thoughts too; however, the write-behind caching is turned off on the CLIENT. I *do wonder* however about the Windows Server 2016 write-behind setting. Is this related to the OpLocks setting mentioned in past server versions?
Not having a Windows Server 2016, I don't really know if the OPLOCKS issue still applies or not. We're still on WS2008R2.
Fred
On Tue, Jun 6, 2017 at 9:20 PM, <mbsoftwaresolutions@mbsoftwaresolutions.com
wrote:
On 2017-06-06 17:18, Fred Taylor wrote:
Sounds like a caching issue.
My thoughts too; however, the write-behind caching is turned off on the CLIENT. I *do wonder* however about the Windows Server 2016 write-behind setting. Is this related to the OpLocks setting mentioned in past server versions?
[excessive quoting removed by server]
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?
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.
Also, those local hard drives as SSDs.
mbsoftwaresolutions@mbsoftwaresolutions.com wrote on 2017-06-08:
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
Mike,
If the share is allowing files to be offline, you might get some wonky behavior. Though, what you are saying doesn't sound like this is the cause. Better to have the tech check to be sure.
Tracy Pearson PowerChurch Software
On 2017-06-13 09:36, Tracy Pearson wrote:
mbsoftwaresolutions@mbsoftwaresolutions.com wrote on 2017-06-08:
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
Mike,
If the share is allowing files to be offline, you might get some wonky behavior. Though, what you are saying doesn't sound like this is the cause. Better to have the tech check to be sure.
Checked. It's not on: http://www2.mbsoftwaresolutions.com/downloads/noofflinecache.png
Very odd.
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]
Mike, Yes error 1104 would point to it being a hardware problem. The very fact that someone has decided to replace a switch would seem to confirm this and no amount of programming will solve the problem as you are very well aware.
Same old story I guess..... blame the software first, discover that it is a hardware issue.... replace the hardware and keep silent about the problem. Oh well, as long as your software doesn't get the blame I guess you are most of the way towards a fix.
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: 05 July 2017 20:29 To: profox@leafe.com Subject: Re: Disappearing (and later reappearing) data on Windows Server 2016 (UPDATED WITH LATEST: ERROR 1104)
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]
On 2017-07-06 03:38, Dave Crozier wrote:
Mike, Yes error 1104 would point to it being a hardware problem. The very fact that someone has decided to replace a switch would seem to confirm this and no amount of programming will solve the problem as you are very well aware.
Same old story I guess..... blame the software first, discover that it is a hardware issue.... replace the hardware and keep silent about the problem. Oh well, as long as your software doesn't get the blame I guess you are most of the way towards a fix.
Dave
Adding that FLUSH command triggered the Error 1104 almost all the time, so I'm glad that I added that to really highlight this issue. I rarely ever use VFP as the backend database, but this is a software from 2003 that they still love and use today.
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.
UPDATE FROM CLIENT:
"[Local IT guy] suggested trying to run the program in Windows 7 Compatibility mode. We tried that on several machines, including Billy K’s, and nothing ghosted. Hopefully that will continue to be the case and we can go forward happily. Suggest you have other customers switching to Windows 10 use 7 compatibility mode."
This still baffles me as to why/how this is happening on Win10 and is resolved by the Win7 Compatibility mode.
mbsoftwaresolutions@mbsoftwaresolutions.com wrote on 2017-07-11:
On 2017-06-08 13:57, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
UPDATE FROM CLIENT:
"[Local IT guy] suggested trying to run the program in Windows 7 Compatibility mode. We tried that on several machines, including Billy K’s, and nothing ghosted. Hopefully that will continue to be the case and we can go forward happily. Suggest you have other customers switching to Windows 10 use 7 compatibility mode."
This still baffles me as to why/how this is happening on Win10 and is resolved by the Win7 Compatibility mode.
Mike,
We had a client do that to us. I remoted in to the workstation and found out the overzealous anti-virus was killing our application due to its "call home" feature. We check for an update to the current version periodically at start up.
When the customer put the program in Compatibility mode, it runs it with more administrative privileges and outside where anti-virus was able to determine it was running. To me, and suddenly aware the tech, it showed how that anti-virus can be avoided. The tech changed out the anti-virus on the computer and our software runs without being in compatibility mode.
I'm not sure if that helps.
Tracy
Tracy Pearson PowerChurch Software
On 2017-07-11 15:13, Tracy Pearson wrote:
mbsoftwaresolutions@mbsoftwaresolutions.com wrote on 2017-07-11:
On 2017-06-08 13:57, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
UPDATE FROM CLIENT:
"[Local IT guy] suggested trying to run the program in Windows 7 Compatibility mode. We tried that on several machines, including Billy K’s, and nothing ghosted. Hopefully that will continue to be the case and we can go forward happily. Suggest you have other customers switching to Windows 10 use 7 compatibility mode."
This still baffles me as to why/how this is happening on Win10 and is resolved by the Win7 Compatibility mode.
Mike,
We had a client do that to us. I remoted in to the workstation and found out the overzealous anti-virus was killing our application due to its "call home" feature. We check for an update to the current version periodically at start up.
When the customer put the program in Compatibility mode, it runs it with more administrative privileges and outside where anti-virus was able to determine it was running. To me, and suddenly aware the tech, it showed how that anti-virus can be avoided. The tech changed out the anti-virus on the computer and our software runs without being in compatibility mode.
Hi Tracy,
The only A/V software is the native Windows Defender, and we had programmed exclusions for all the VFP data file types as well as excluded the local app and network database folder.
Odd.
I remember 'opportunity locking".... https://www.google.com.hk/search?q=opportunity+locking&ie=utf-8&oe=u...
On Wed, Jun 7, 2017 at 5:18 AM, Fred Taylor fbtaylor@gmail.com wrote:
Sounds like a caching issue.
On 2017-06-09 07:47, Man-wai Chang wrote:
I remember 'opportunity locking".... https://www.google.com.hk/search?q=opportunity+locking&ie=utf-8&oe=u...
but that's on the SERVER, right? To reiterate, this Server 2016 has been in place for a short time but the Windows 7 clients never had the issue; they only experienced the issue after upgrading the clients to Windows 10.
This design is using a VFP DBC on their file server, and the application uses local views. Rock solid since 2003.
-
Dave Crozier -
Fred Taylor -
Man-wai Chang -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Tracy Pearson