I have a client where people who leave MDGP 2013 untouched for a while receive an error message stating "A remove range operation on table 'syContentPageXMLCache' cannot find the table" when they resume using GP.
The More Info is "[Microsoft][SQL Server Native Client 10.0][SQL Server]Invalid object name '##1675106'".
It looks to me like it might be a timeout but I wondered if anyone could shed more light on the issue? Hopefully including a resolution.
This is Microsoft Dynamics GP 2013 running on SQL Server 2012.
Author of azurecurve|Ramblings of a Dynamics GP Consultant
Microsoft Most Valuable Professional for Dynamics GP in 2013 and 2014.
Senior Consultant at Perfect Image Ltd
Perfect Image/ Dynamics GP
Tel: +44 (0) 843 289 2656
Equinox House, Cobalt 3.2, Silver Fox Lane, Silverlink, North Tyneside, NE27 0QJ, United Kingdom
You can try by setting as 'Never' for sleep mode.
I have seen errors like FP:Couldn't Close table when users do not use their machine for sometime. This error occurs due to the interruption in network connection as system goes to sleep mode. I have seen results by changing the sleep option to Never for this error. I would suggest you can also try this.
Hope this helps.
RENJAN MATHEW VARUGHESE
DYNAMICS GP CONSULTANT, MCP, PMP
Where is this setting?
Do you have any third party products installed on GP? There is one that logs people out after a specific amount of time. You may need an upgrade to this.
Richard L. Whaley Author, Publisher, Consultant
Enhancing your Dynamics Knowledge!
No, there are no third party addons.
The setting is in Control Panel >> PowerOptions.
Click on 'Change plan settings' for the plan which is selected.
Select 'Never' for 'Put the computer to sleep'
Control Panel>Power options...
I have seen this in GP 10, when the default settings were changed the interruptions stopped.
Thanks for posting this. We have a client that also is getting this error, and, thanks to you, we now have a fast resolution. Thanks to Rejan, too, for the solution!
Judy Hirst CMA
Senior Financial Systems Consultant| Etelligent Solutions
(403) 204-6930 | email@example.com
Is there any other settings to check regarding this issue? I have a client with the same issue occurring on the Terminal Server - I checked the Power Options on both the SQL Server and the Terminal Server and the 'Put The Computer To Sleep' is set to NEVER for both machines.
Anything else that can cause the Network Connection to timeout or cause connection issues?
I was wondering if you had every determined a solution to your problem noted above.
I have a client in the same configuration -Terminal Server, GP2013, SQL 2012 - who left their GP session running while working on a spreadsheet for about 10 min this morning and when she re-clicked on the GP Screen to get more information, she got this error.
She had to 'quite' from the system and got the FP: Cant Close Table error message - then restarted her GP session and was for a couple of hours - then she got the same cycle of error messages again.
Hope there is a better solution available than to not have the server sleep - which by definition I don't think the Remote Application on Terminal server can do.
** Please, if this answers your question, mark it as 'Answered' so others experiencing the same will know it resolved your issue. **
Bill CampbellDirector, OperationsM.I.S. Management Information Solutions Ltd.Skype: billc.edmontonCell: +1 780 994 2455Off : +1 780 481 5564
With my client, the issue was the Terminal server was running in a virtual environment and the network connection was paused every time a snapshot of the virtual environment was performed. This seems to have been the cause of the issue for them.
I have gotten this error a couple of times. Does anyone know what is happening?
It looks like there's a SQL temp table that's being referenced, possibly for the Information Pane area of a list. (Just guessing on the where the temp table is used, based on the name displayed in the original error.)
When the GP client machine falls asleep, the SQL connection will eventually be dropped by SQL Server. Since the temp table isn't being accessed any longer, it goes away on the SQL Server. When the client wakes up, the GP instance doesn't know that the temp table is no longer valid, so it continues trying to access it, resulting in the error that the temp table couldn't be found.
The solution of preventing the GP client machines from falling asleep seems like the best course of action.
Steve - That would make sense if the GP Client falls "asleep", but with the client I am working with, the terminal server did not go into "sleep" mode. We would be actively working in Dynamics GP - Stop processing to discuss some fields and then attempt to continue the process, and then we encounter the issue.
I had a similar experience with a client a few months ago, and originally thought the problem might be due to power management settings on the machines, putting the machines to sleep when left alone. It turned out to be a combination of power management, and a problem with DNS configuration on machines. The users were switching the DNS settings on the machines manually to use the google public DNS server 18.104.22.168 in order to get around the company's network controls, which keep people from shopping at work, and other distractions.
The users then created a host file to manually point to the various servers on the network, because internal servers couldn't be resolved by goolge's public DNS servers. So here's where problems arise - apparently resolving via a host file isn't a problem for GP on first contact, but something about waking from sleep presents a problem such as the one you're encountering.
In any event, the next time you see the error above, try pinging the server as well, it may be instructive. If the circumstances above don't fit, you might have another problem with DNS, so you might want to run ipconfig /flushdns from a command prompt on affected machines, then try pinging the server using it's name, not IP address.
If my answer has helped you, please verify the answer by clicking yes to the right of the answer. This helps others identify the solution to the problem, should they encounter a similar issue.
http://redbeardblogging.blogspot.com | MCP-GP MFG
Regardless of the order of the steps outlined in any solutions I might propose - First, and foremost, make a backup!