Adjust Cost Item Entries Takes Too Long

melsadek
Member Posts: 31
Hi there,
We have a manufacturing and fabrication customer that heavily uses the Manufacturing functional area of NAV 2009 Classic. One of their biggest challenges right now is that as their Item Ledger (and consequently their Value Ledger) grows, their Adjust Cost Item Entries (ACIE) routine takes a long time to process completely. In recent months not even a full 24 hour run cycle is getting it done. Couple that with the fact they run their plant 24/7, and the frustration of not getting this report to run successfully starts to mount.
In another topic someone mentioned that it might be worthwhile to add a COMMIT to the adjust cost routine after each item is processed in order to atomize the transaction, so that if the routine must be killed not all the work is lost (and consequently avoid the dreadful transaction log rollback). I'm not too sure where the COMMIT should be added, but I did insert it into the Inventory Adjustment codeunit in the following function:
I need to get this done for the client, but first I'd like to ask the community if this is the proper place to put it in, and if there are any concerns I should be aware of due to this commit.
Your feedback is appreciated.
We have a manufacturing and fabrication customer that heavily uses the Manufacturing functional area of NAV 2009 Classic. One of their biggest challenges right now is that as their Item Ledger (and consequently their Value Ledger) grows, their Adjust Cost Item Entries (ACIE) routine takes a long time to process completely. In recent months not even a full 24 hour run cycle is getting it done. Couple that with the fact they run their plant 24/7, and the frustration of not getting this report to run successfully starts to mount.
In another topic someone mentioned that it might be worthwhile to add a COMMIT to the adjust cost routine after each item is processed in order to atomize the transaction, so that if the routine must be killed not all the work is lost (and consequently avoid the dreadful transaction log rollback). I'm not too sure where the COMMIT should be added, but I did insert it into the Inventory Adjustment codeunit in the following function:
MakeSingleLevelAdjmt(VAR TheItem : Record Item) LevelNo[1] := LevelNo[1] + 1; UpDateWindow(LevelNo[1],WindowItem,WindowAdjust,WindowFWLevel,WindowEntry,0); TheItem.SETCURRENTKEY("Low-Level Code"); IF TheItem.FINDLAST THEN TheItem.SETRANGE("Low-Level Code",TheItem."Low-Level Code"); WITH Item DO IF TheItem.FINDSET THEN BEGIN REPEAT Item := TheItem; GetItem("No."); UpDateWindow(WindowAdjmtLevel,"No.",WindowAdjust,WindowFWLevel,WindowEntry,0); REPEAT LevelExceeded := FALSE; AdjustItemAppliedCost; UNTIL NOT LevelExceeded; AdjustItemAvgCost; PostAdjmtBuf; UpdateItemUnitCost; // After adjustments are made on that particular item, commit to the database COMMIT; UNTIL (TheItem.NEXT = 0) OR LevelExceeded; END;
I need to get this done for the client, but first I'd like to ask the community if this is the proper place to put it in, and if there are any concerns I should be aware of due to this commit.
Your feedback is appreciated.
Mohamad El-Sadek, MCP, MBSS, MCTS
G.R. & Associates, Inc.
G.R. & Associates, Inc.
0
Comments
-
You say "NAV 2009 Classic" but that looks like older version code. Can you verify your NAV database version?
What have you done in terms of improving the runtime performance of Adjust Cost?There are no bugs - only undocumented features.0 -
I can confirm they're using NAV 2009 R2 objects.
I haven't touched optimization of this report yet, because it's a much lengthier endeavour. Right now I'm solely interested in making sure I have a proper COMMIT after each item is adjusted.Mohamad El-Sadek, MCP, MBSS, MCTS
G.R. & Associates, Inc.0 -
You're right on the code. Not sure what I was looking at. :oops: (Downside of working with so many different systems and versions)There are no bugs - only undocumented features.0
-
So can you confirm for me about the COMMIT's location?Mohamad El-Sadek, MCP, MBSS, MCTS
G.R. & Associates, Inc.0 -
melsadek wrote:So can you confirm for me about the COMMIT's location?
The way adjust cost is written it must run through to completion without any possibility of having the results partially committed. This is primarily because of the AppliedEntryToAdjustBuf. This is a temporary table that is written to throughout the process. Near the end of the entire process SetAppliedEntryToAdjustFromBuf (called from MakeMultiLevelAdjmt) uses this temporary table to update the “Applied Entry to Adjust” field in the Item Ledger Entry table. By committing the data after processing each item you run the risk that the process will end leaving some data committed but the "Applied Entry to Adjust" field not properly updated.
Additionally, the periodic commits will release locks on the tables and allow other users to post inventory transactions. This will cause problems with the Item Register that adjust cost creates and expects to remain valid throughout the entire process.0 -
Be very careful about adding COMMITs unless you fully understand the entire process. It this case what you are suggesting is definitely not correct.
The way adjust cost is written it must run through to completion without any possibility of having the results partially committed. This is primarily because of the AppliedEntryToAdjustBuf. This is a temporary table that is written to throughout the process. Near the end of the entire process SetAppliedEntryToAdjustFromBuf (called from MakeMultiLevelAdjmt) uses this temporary table to update the “Applied Entry to Adjust” field in the Item Ledger Entry table. By committing the data after processing each item you run the risk that the process will end leaving some data committed but the "Applied Entry to Adjust" field not properly updated.
Additionally, the periodic commits will release locks on the tables and allow other users to post inventory transactions. This will cause problems with the Item Register that adjust cost creates and expects to remain valid throughout the entire process.
Thanks for that explanation. So then where would you recommend I place it? Or do you not recommend it at all?Mohamad El-Sadek, MCP, MBSS, MCTS
G.R. & Associates, Inc.0 -
melsadek wrote:Thanks for that explanation. So then where would you recommend I place it? Or do you not recommend it at all?0
-
You are right keeping an eye on everything jreynolds has written. First think about the frequency ACIE is run. The job should be able to finish in a sufficient timeframe.
For your current problem you might think about creating a worklist table and running ACIE (Report 795) for each item first before increasing the frequency.Cheers
Carsten
==> How To Ask Questions The Smart Way
This post is my own opinion and does not necessarily reflect the opinion or view of my employer.0 -
Hi SilverX,
Do you mean to say the location of the COMMIT is correct, or do you mean to say that it is not correct and I should follow jreynolds advice?
I am thinking of creating an item dataitem as an outer loop on the ACIE report and place my commit there. That way the adjust cost routine data is commited to the DB after the ACIE report completely finishes adjusting values for a particular item. What do you think?Mohamad El-Sadek, MCP, MBSS, MCTS
G.R. & Associates, Inc.0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions