web
You’re offline. This is a read only version of the page.
close
Skip to main content
Community site session details

Community site session details

Session Id :
Microsoft Dynamics GP (Archived)

SQL nesting level exceeded error message when using PSTL

(0) ShareShare
ReportReport
Posted on by 28,058 Moderator

Does anyone used recently the PSTL utility to apply changes to GL accounts in  GP2010?

I have the error coming on screen when trying to use the PSTL tool to change GL Accounts from one segment to another... Renaming accounts (non-existant destination) seems to work fine, but Accounts that need to be merged with an existing account poses a serious issue and can't be converted. I've tried both avenues (file import or direct input) and none of them work.... I looked at the GL00100 table and can't find custom triggers aside of the one put in place by the PSTL (starting with ta... ). I also see 3 triggers starting with glp... and that covers the inset, delete and update actions. They do look like coming from GP, but I couldn't say for sure. They have a date of creation quite recent (when the last YE Tax update was applied)... but they seem to have been there for a while.

I did run also a DEX trace log, but the last statement that is called before the error is a stored procs... : zDP_SY02100SS_1 and then right after an SP declare : BEGIN DECLARE @stored_proc_name char(28) DECLARE @retstat int DECLARE @param5 int set nocount on SELECT @stored_proc_name = 'FTI.dbo.smChangeAccountIndex' EXEC @retstat = @stored_proc_name '2274', '2435', 2274, 2435, @param5 OUT SELECT @retstat, @param5 set nocount on END

after which I get the SQL nested error message :

/*  Date: 03/06/2013  Time: 13:39:42
SQLSTATE:(37000) Native Err:(217) stmt(13379536):*/
[Microsoft][SQL Server Native Client 10.0][SQL Server]Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32).*/

Any ideas where to start look for ?

*This post is locked for comments

I have the same question (0)
  • Verified answer
    Beat Bucher  GP Geek  GPUG All Star Profile Picture
    28,058 Moderator on at
    RE: SQL nesting level exceeded error message when using PSTL

    Hi Tim,

    I had to redo some Account Changes with the PSTL tool in GP 2010 and hit the same error again... since I didn't recall what I did the last time, I just used the SQL trace utility to narrow down what procedure or code was causing the error... in this case it stopped on the "taGLModifyAccount" SP and I knew it had something to do with a trigger (thanks to the blog post of David Musgrave)...

    I opened a query window in SQL to try the execution of the SP alone since it didn't required any parameters (at least nothing important)... The SP stopped after a short time and throwed the following error :

    Msg 217, Level 16, State 1, Procedure zDT_POP10110U, Line 1
    Maximum stored procedure, function, trigger, or view nesting level exceeded (limit 32).

    At this moment I knew right of the bat what the problem was...  The PSTL was run off a Test bed system that was updated with the latest service pack, but since no one is really working in this environment, the bug about the POP10110 table wasn't reported yet. Many years back our MBS partner had apparently developed some code for the POP module in GP that includes the replacement of some default SP, and any time GP gets an update, that SP that is called by an update trigger of the table POP10110 is re-enabled in the system.. thus generating other error messages when people try to edit a PO.

    In our case I've a SQL script that runs across all the GP companies and disables that SP, so it doesn't conflict with the custom SP from our partner...

    I was never able to figure out what the purpose of this customization was, and even our partner may not recall, but this is a perfect example on how badly documented system changes can have an impact years after they were implemented.

    Until next time...

  • Tim Foster Profile Picture
    8,515 on at
    RE: SQL nesting level exceeded error message when using PSTL

    Beat,

    A few things:

    1. You can't change the server configuration Nesting Level Limit - 32 is it.

    2. Many of the PSTL stored procedures are stored in SQL Server as encrypted.  The details of what they do can't even be seen in SQL Profiler.  Your DEX trace might actually be returning more detail than SQL would.  I suspect decrypting the Stored Procedure violates licencing - so don't do it.

    3. In your DEX trace, can you see the broader pattern where one stored procedure calls the next stored procedure calls the next...(32 times, like a cascade)?  How many accounts are you trying to merge at once?  Have you tried one (1) account at a time (even if it is painfully slow)?  The Dynamics GP code usually doesn't use recursive SQL calls (I think Btreive and C-tree couldn't even do it).  However,  I have seen loops caused by triggers and cursors.

    In a test environment, you could add a bit of code to a stored procedure to help you trace.  In SMSS, script the stored procedure as a drop and replace.  Use SQL formatter to reformat the code.  Add some SQL Print statements to help you see where you are.  The DEX log will show you the Printed statements.  @@NESTLEVEL in SQL will return the current nesting level.  

    Tim

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Abhilash Warrier – Community Spotlight

We are honored to recognize Abhilash Warrier as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans