Table error upon closing GP

(0) Share

Report

Posted on by Community Member

I have a user who has reported this error to me. When he closes GP he gets two errors. The first one that comes up says "A remove range operation on table 'syContentPageXMLCache' cannot find the table. He will then hit OK and that error will go away.

Then a second error message will pop up that says "FP: Couldn't close table!" At this point he will hit ok and the message will pop up about 4 more times he said he will just hit ok each time and at the fifth time of popping up it will then shut GP down.

Does anybody have any indication as to why this is happening and how I can more to rectify it? I have screenshots of the error but cannot upload them here. Thank you.

*This post is locked for comments

I have the same question (0)

All responses (6)

Answers (1)

Richard Wheeler 75,848 Moderator on at

Like (0)

Report

"FP: Couldn't close table!" is usually an indication of lost network connection. I would start by checking the patch cables both to the computer and to the walls. After that, swap spots in the router.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I'll do this tomorrow but I'm not confident it's the root of the problem. We're able to navigate through network shares, send email,get out to the internet, etc.... so it doesn't seem like it's a problem with connectivity. But, I will double check all of this tomorrow to eliminate this as a variable.

Was this reply helpful? Yes No
Verified answer

Richard Wheeler 75,848 Moderator on at

Like (1)

Report

Is it possible this person's computer goes to sleep and that may be what is causing this message? Can you try adjusting the power options to not go to sleep.

Was this reply helpful? Yes No
Suggested answer

L Vail 65,271 on at

Like (1)

Report
Below are some things that could cause the ‘FP:Can’t close table!’ error message to occur. Most of this information was taken from David Musgraves blog, but other articles also provided information, I just cannot remember from where they originated.

The first item on the list is a temporary loss in connectivity with the SQL server.

The error: “FP: Can't close table!" can happen if there is even the slightest glitch in your connection to the SQL server. What happens is that the procedure you are running creates a temporary table in the SQL tempdb database and stores a pointer to it. Once there is any kind of connection problem, it loses the pointer and can no longer communicate with the table. 'FP" stands for 'Form Processing", so there's a procedure that can't close the table because the table’s address is not valid.

Another cause could be that the Anti-virus program you are using is setup to scan the Microsoft Dynamics GP2010 folder on the workstation and/or scan the SQL or Microsoft Dynamics GP2010 folder on the Server. It might flag essential files as suspect, or delete them altogether.

If you can exclude certain folders on your workstation from being scanned, this could solve the problem. Has there been any changes to any of the antivirus software on either the workstation or the server ?

The directories that you will want to exclude are:

On the Server:

C:\Program Files (x86)\Microsoft Dynamics\GP2010 including subfolders

The folders holding the SQL Server files

The shared folder that contains the Reports.dic or Forms.dic files:

\\MSDYN\DynamicsShare\DynamicsReports

The %TEMP% folder

On the Client or Terminal Server:

C:\Program Files (x86)\Microsoft Dynamics\GP2010 including subfolders

The %TEMP% folder

You could get the message when you use SmartList against a large number of records (like the SOP or PO line items). This problem occurs because SmartList can’t find a continuous block of memory that is large enough to perform the search. Not only is SmartList a memory hog, but it needs to have a continuous block of memory.

To resolve it, either get more memory or use a refreshable excel report instead of SmartList. Excel is most likely the better answer, as a bonus, you can sort and filter Excel by many more columns.

Third-party products can also cause errors. Custom code could interfere with the normal business logic of GP and cause tables to behave improperly.

It can also happen if you are using a modified form – you’ll know it is modified if there is a dot in front of the window name.

Another reason is that you have a buildup of TNT* files in your temp folder.

You’ll want to occasionally delete any TNTXXX*.tmp files in your temp folder. Delete the files when you are not logged in to Dynamics. You can get to your temp folder by typing %temp% in the file explorer address bar.

Here’s how the problem manifests itself:

When Dexterity (the programing language behind GP) needs a temp file, it generates a hexadecimal name for it using the format TNTXXX*.tmp (working as a placeholder file). It then checks to see if that file name is already being used. If it is, it will generate a new hexadecimal value and try again.

Once Dexterity has a file name that isn’t being used, it will create a placeholder which tells other procedures that this file name is now ‘taken’. Dexterity will then attempt to use the TNT*.dat and TNT*.idx files using the hexadecimal value it came up with. Dexterity expects that the corresponding TNT*.dat and TNT*.idx files do not exist initially because it didn’t find a flag saying they were taken.

Since Dex doesn’t think the files exist, when the file is first accessed, it tries to create it. When Dex tries to re-use the existing TNT*.dat and TNT*.idx files, which were previously created for a different table definition, the errors are generated.

Kind regards,

Leslie

Was this reply helpful? Yes No
Derek Albaugh on at

Like (1)

Report

Leslie is correct with that information.

To add some other things we've seen help verify and/or resolve connection-type issues such as this:

>>If you are running an Active Directory Domain environment, you may need to try disabling TCP Chimney. The following KB article informs how to do this:

support.microsoft.com/.../951037

>>Settings to Check:

1. Go to (Start | Run) and type cliconfg.exe and click on run.

2. On the General tab on the right under 'Enabled protocols by order:' make sure TCP/IP is the top one.

3. Highlight TCP/IP and click on Properties

4. Make sure the default port is 1433, (unless you have configured it to be a different port)

a. Ensure no firewalls inside your network are blocking or scanning this port.

5. Click Apply then Ok

>>Continuous Ping:

You could setup a continuous ping to run on your SQL server to the problem workstation or problem terminal server:

ping workstation -t -l 65500

(Replace workstation with the actual name of the workstation that you are pinging).

You could also setup a continuous ping to run on your problem workstation or problem terminal server:

ping sqlservername -t -l 65500

(replace sqlservername with the actual name of the SQL server that you are going to ping)

Let these pings run for 10 - 15 minutes and then enter “Ctrl C” to end the continuous ping. Review this to see if any packets are lost. You might see a message such as, “a timeout occurred” as well. This indicates that the connection is being severed.

>>Data Execution Prevention

Click the Start menu.

Right click on My Computer.

Click on Properties.

Click Advanced System Settings.

On the Advanced tab click on the Settings button in the Performance section.

Click on the Data Execution Prevention tab.

Select the second Radio Button labeled: Turn on DEP for all programs and services except those I select.

Click on the Add button at the bottom of the window.

Navigate to the install folder for GP10.0.

Select the Dynamics.exe file and click open.

Verify that it has a Checkmark in the box for Microsoft Dynamics GP and click Apply at the bottom of the window.

>>If you have Symantec Endpoint Protection installed and configured on the machines, try completely removing it from one machine as a test. Dynamics GP has known issues with Symantec Endpoint Protection, specifically the 'Application and Device Control' feature in Symantec 11.0.

>>Also, we've started seeing issues with Sonic Wall's VPN application. Even when the users aren't actively using VPN, Sonic Wall appears to have a type of firewall built in that can block traffic it doesn't recognize, which we've seen it do with Dynamics GP. We've seen this when attempting to login to Dynamics GP and also when running reports such as SmartLists.

Thank you,

Was this reply helpful? Yes No
L Vail 65,271 on at

Like (0)

Report

Thanks Derek,

I will add you suggestions to my list!

Kind regards,

Leslie

Was this reply helpful? Yes No