I talked before in a previous blog post about the “syContentPageXMLCache cannot find table” error. This and its cousin the “FP: Couldn’t close table!” error are caused by something severing long lived SQL connections between the client and server.
This might be due to networking issues like bad routing, physical faults with NIC cards, faulty Ethernet cables or connectors, servers going to sleep, connectivity problems (WIFI) or many other potential causes.
The problem
I found myself involved in this today. A new employee started, since they have been working for us, every time the Dynamics GP application is closed at the end of the day (or sooner) they get the FP Couldn’t close table error. They have also been getting other SQL related errors.
IT support had already tried:
- New GP user ID for the user
- Rebuilding the PC from the standard image
- Swapping the newer PC hardware the new user got, for the same hardware the rest of the users are using, involving another new image rebuild.
- Deleting the user’s AD profile and rebuilding it.
- Swapping the Ethernet cables
- Swapping to another wall port of a user that is known to work, also on another network switch
- Checking power saving sleep options on the NIC
None of the above has stopped the issue occurring. It came to a head when a quotation was entered, that ended up pulling the wrong currency for pricing (as I suspect the SQL connection broke under the hood). I was stumped as to what the issue could possibly be bearing in mind what had already been tried.
Resolving the issue
The user was instructed to email me the screenshots of the errors, the second they happened. Not long after, I came back from my lunch to see an email come in. Attached was the stereotypical errors caused by connection loss.
I connected to the event log on the offending machine, looked at recent history and found the problem.
Although the power settings in windows 10 and it looked ok from the top level screen. When drilling into “Change advanced power settings” and checking through all the options, the “Allow hybrid sleep” setting was set to ON. Looking at the other machines in the area, they all were set to OFF.
So my current working assumption is that the user had come back from lunch, during which time the machine had snoozed, causing the SQL connection to drop, with the following errors on resuming using GP:
David Musgrave has in the past posted some more information on these kinds of issues that are worth a read:
More on SQL Server Connection issues with Microsoft Dynamics GP