There is not enough memory to run this function

bbrownbbrown Member Posts: 3,268
I have built a process that creates to purchase credit memos and 1 or 2 sales orders and then post them. All documents are created by calling "Copy Document". All documents create fine but when the posting starts I get the above error on the first document.

I am using the same posting code (CU 90) that is used in base system. So I'm comfortable that I don't have a recursive loop.

I set the debugger and it always stops at the same place in CU 90. A FINDSET on the purchase line table.

The documents are small. 1 to 3 lines each.

Any thoughts?
There are no bugs - only undocumented features.

Answers

  • DaveTDaveT Member Posts: 1,039
    Hi,

    Normally I have come accross this error in production where the is a recursive call gone mad because of a BOM referencing itself. What the call stack like when it stops in the debugger?
    It the function finding the record is after creating and then creating another...etc?
    Dave Treanor

    Dynamics Nav Add-ons
    http://www.simplydynamics.ie/Addons.html
  • bbrownbbrown Member Posts: 3,268
    The stack just shows the call of codeunit 90 from my function. It breaks on a FINDSET in codeunit 90. It does even start to loop thru the records. It's the fist all to CU 90.
    There are no bugs - only undocumented features.
  • DaveTDaveT Member Posts: 1,039
    Hi,

    Sound like the Record Set property is high on the database. You could try changing this setting.

    Also did you try substituting with a find('-')
    Dave Treanor

    Dynamics Nav Add-ons
    http://www.simplydynamics.ie/Addons.html
  • bbrownbbrown Member Posts: 3,268
    The FINDSET is a piece of base code in CU 90. I'm a bit hesitant to change this as CU 90 is otherwise working fine. I am not asking the system to post anything it doesn't do several times on any given day. I am working in a development copy so I can "experiment" a bit with these settings.

    The record set is set fairly high. It's been this way for quite some time. We found that we got much better performance on several critical functions with it set high. I won't claim the setting to be optimal but no one has been complaining about performance.

    If the issue was either of these, wouldn't you expect to see problems with CU 90 during any purchase posting?
    There are no bugs - only undocumented features.
  • bbrownbbrown Member Posts: 3,268
    The record set does seem to make a difference. I dropped it back to the default 500 records and my process ran without error. However I do see a very noticable performance drop in some other common functions. Deleting a small sales order took noticably longer. Guess I need to test a bit to find an optimal setting.

    Thanks for the assistance.
    There are no bugs - only undocumented features.
  • DaveTDaveT Member Posts: 1,039
    Glad to Help :mrgreen:
    Dave Treanor

    Dynamics Nav Add-ons
    http://www.simplydynamics.ie/Addons.html
Sign In or Register to comment.