We have the same issue; the fix may have helped a little, but ultimately the memory leak still exists.
To work around the issue we have to limit the amount of data we load at one time, then close and reopen Axapta to free the leaked memory. We rearchitected our import class so that it could handle multiple instances running at the same time, and limit each instance to no more than 10MB of EDI data (which is read into a staging table then posted). The amount of data, SOs, Lines you can do at one time will be dependent on your exact machine and SO configuration, so you'll have to determine what the safe number is for your appilcation. For large loads we'll run 3 instance on each of 2 machines with FAT connections to get the data loaded. In our busiest invoicing period, we have to do it twice. The rest of the year 1 iteration of 1 to 6 instances will do it. --- In Axapta-Knowledge-Village@yahoogroups.com, "Hennie Potgieter" <[EMAIL PROTECTED]> wrote: > Hi Kim, > > We do have the SmartHeapMemorySizeUp() in our Info.Startup method > exactly as you describe and the problem still occurs after 3500 odd > sales orders posted from 1 client. > > Hennie > > -----Original Message----- > From: Axapta-Knowledge-Village@yahoogroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of Kim > Truelsen > Sent: Tuesday, 26 July 2005 13:06 PM > To: Axapta-Knowledge-Village@yahoogroups.com > Subject: RE: [Axapta-Knowledge-Village] Posting Memory Leak > > > > In Sp3 we made a change in Classes / Info / Startup. Please implement > that change and hopefully your problem is gone. > > > > void startup(str startupCommand) > > { > > this.docuInit(); > > > > if (xGlobal::clientKind() != ClientType::Server) > > SmartHeapMemorySizeUp(); > > > > Med venlig hilsen / Best regards > > Kim Truelsen > Escalation Engineer > Microsoft Business Solutions Axapta > EMEA Global Technical Support Center > > Direct / mobile: +45 4489 0786 / +45 29499958 > E-mail: <mailto:[EMAIL PROTECTED]@microsoft.com> [EMAIL PROTECTED] > > Online support at: <BLOCKED::http://www.microsoft.com/support> > www.microsoft.com/support > MBS Partnersource at: > <BLOCKED::http://www.microsoft.com/BusinessSolutions/PartnerSource/de fau > lt.mspx> www.microsoft.com/BusinessSolutions/PartnerSource/default.mspx > Security Updates at: <BLOCKED::http://www.microsoft.com/protect> > www.microsoft.com/protect > > <BLOCKED::http://www.microsoft.dk/> Microsoft Denmark > Tuborg Boulevard 12 > DK-2900 Hellerup > Phone:+45 4489 0100 / Fax: +45 4468 5510 > > > _____ > > > If you have any feedback about my work, please let either myself or my > manager Kenneth Stubban know at > <BLOCKED::mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] or > telephone +45 4489 0784 > Note: This email may contain confidential information. If you are not > named on the addressee list, please take no action in relation to this > email, do not open any attachment and please contact the sender (details > above) immediately. > > > _____ > > > From: Axapta-Knowledge-Village@yahoogroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of Hennie > Potgieter > Sent: 26. juli 2005 13:00 > To: Axapta-Knowledge-Village@yahoogroups.com > Cc: Edine Le Roux > Subject: [Axapta-Knowledge-Village] Posting Memory Leak > > > > Hi, > > > > We are still experiencing problems with the standard sales order posting > process in Axapta v3 SP2. It seems as if the standard posting routine > in Axapta has a memory leak that causes Ax32.exe to crash with an out of > memory error. Has anyone of you experienced this before and do you have > any recommendations for us in this regard? The details are as follows: > > > > We get the SmartHeap Out of Memory error when trying to import and post > individual sales orders from an external system. The invoices get > imported into Axapta and then posted. This posting happens on a per > sales order basis. (Import 1 sales order from the external system into > the temporary posting tables and then post the sales order) We suspect > that this is due to a memory leak in the Axapta standard posting > process. (Class.SalesFormLetter). For each sales order that is posted, > a certain amount of memory is allocated (as can be seen in the Windows > task manager) and added to the total memory usage of the Ax32 process. > Only a small amount of the added memory is released after the posting > process. This cause the total memory usage of the Ax32 process to keep > growing. (Typical memory leak behaviour). This causes the SmartHeap Out > of Memory error after a variable amount (about 3500) of sales orders > were posted. We have tracked this down to the SalesFormLetter.post () > instruction in Axapta. The posting is run from a client PC and the > error occurs in both 2 and 3-tier mode. > > > > The standard Axapta posting procedure, in SalesFormLetter.run(), is > called for each sales order imported. (The code causes the memory leak). > > > > The SmartHeapMemorySizeUp() value has been set. > > > > Do anyone have any suggestions in this regard? > > > > Regards, > > > > -* > > Hennie Potgieter > > Senior Business Analyst > > UTi SUN Couriers Division > > Centurion, South Africa > > Cell: 0829208315 > > mailto: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] > > > > > > > > > Sharing the knowledge on Axapta. > > > > > _____ > > YAHOO! GROUPS LINKS > > > > * Visit your group "Axapta-Knowledge-Village > <http://groups.yahoo.com/group/Axapta-Knowledge-Village> " on the web. > > > * To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED] subject=Uns > ubscribe> > > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/> . > > > _____ Sharing the knowledge on Axapta. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/Axapta-Knowledge-Village/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
