Very slow upgrade (manufacturing)

Alisha
Member Posts: 217
Hi all,
I'm running the upgrade processes from 2.60 -> 4.00, and now is processing the table "Finished production order".
The process is running very slow (it's going to take about 10 days at this rate..). I've deactivated all the keys from the tables related to "Finished production order", same way that I did with "Item ledger entry", but it didn't have any effect..
I've done another upgrades like this and never had this problem, it seems that it's the first time there are an important amount of records related to Manufacturing..
Any help?
Thanks a lot
I'm running the upgrade processes from 2.60 -> 4.00, and now is processing the table "Finished production order".
The process is running very slow (it's going to take about 10 days at this rate..). I've deactivated all the keys from the tables related to "Finished production order", same way that I did with "Item ledger entry", but it didn't have any effect..
I've done another upgrades like this and never had this problem, it seems that it's the first time there are an important amount of records related to Manufacturing..
Any help?
Thanks a lot
0
Comments
-
Not directly tips for the manufacturing, but in general.
1) use a server to do it with multiple disks, enough RAM and thus DB-cache with the COMMIT-cache enabled.
2) run the fin.exe on the server, not on a client.
3) You should check the code to see what is does. Sometimes it can be useful to leave or even to create a new index just for the upgrade process. In the code something like "IF Table.SETCURRENTKEY(...) THEN ;" can be put in case the index exists to use it. If it doesn't exist, it will not generate an error but it will go slower.Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!0 -
I ´ve had a simliar problem.
In my case a item ledger entry with Number 0 was the problem.0 -
I've already done all of this... the table Item ledger entry is much bigger and it took 1 day to process it... I don't understand what's happening now.
I don't know if there is an entry with number 0.. but could it be the problem? How can an entry with number 0 make it run so slowly?0 -
The problems seems to be in the table 99000815 "Finished prod. order". It has only 77000 records, but it takes about 15 days to complete the process of upgrading this table.
The process begins running fast, but it gets slower and slower.. can it be a problem with the cache memory?
We have decided to delete old production orders (from before 2003 year), but this will not solve the problem next time if another customer has more records on this table.
I have optimized all the keys, and de-activated the ones that I don't need.
Any help?
Thanks0 -
Table 104037:"State Indicator" Function "Update()"
This is more or less the code. So every 100 milliseconds, the dialogbox is updated. Also this takes time.RecordNo := RecordNo + 1L; TableRecordNo := TableRecordNo + 1L; IF ABS(TIME - LastUpdateTime) > 100 THEN UpdateWindow;
This is better : every 3 seconds:RecordNo := RecordNo + 1L; TableRecordNo := TableRecordNo + 1L; IF ABS(TIME - LastUpdateTime) > 3000 THEN UpdateWindow;
Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!0 -
Alisha wrote:The problems seems to be in the table 99000815 "Finished prod. order". It has only 77000 records, but it takes about 15 days to complete the process of upgrading this table.
Can you post the the code of the function that is going slow?Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!0 -
This is the code that takes sooo long:
TransFnshdProdOrder
FnshdProdOrder.SETCURRENTKEY("Nº orden lanzada");
WITH FnshdProdOrder DO
IF StateIndicator.UpdateTable(TABLENAME) THEN BEGIN
TimeLog.TimeLogInsert(TimeLog,TABLENAME,TRUE);
IF FIND('-') THEN
REPEAT
StateIndicator.Update;
ProdOrder.INIT;
ProdOrder.TRANSFERFIELDS(FnshdProdOrder);
ProdOrder.Status := ProdOrder.Status::Finished;
ProdOrder."No." := "Nº orden lanzada";
ProdOrder.INSERT;
TransFnshdProdOrderLine(FnshdProdOrder);
TransFnshdProdOrderRtngLine(FnshdProdOrder);
TransFnshdProdOrderComp(FnshdProdOrder);
TransFnshdProdOrderRtngTool(FnshdProdOrder);
TransFnshdProdOrderRtngPersnl(FnshdProdOrder);
TransFnshdProdOrdRtngQltyMeas(FnshdProdOrder);
TransFnshdProdOrderCmtLine(FnshdProdOrder);
TransFnshdProdOrderRtngCmtLn(FnshdProdOrder);
TransFnshdProdOrderBOMCmtLine(FnshdProdOrder);
TransFnshdProdOrderLedgEntry(FnshdProdOrder);
miventana.UPDATE(1,ProdOrder."No.");
UNTIL NEXT = 0;
DELETEALL;
TimeLog.TimeLogInsert(TimeLog,TABLENAME,FALSE);
StateIndicator.EndUpdateTable(TABLENAME);
END;
To see these functions you have to import the objects to migrate from 2.60 - 4.00 with manufacturing, the fob is called Upgrade260400.1.MFG and Upgrade260400.2.MFG.
The table "Finished prod. order" had 77.000 records, and it took about 15 days to finish. Deleting 50.000 records (from past prod. orders , older than year 2003), it was reduced to 15 hours. It seems that the amount of time needed grows exponentially..
Thanks all for your help!0 -
Alisha wrote:TransFnshdProdOrderLine(FnshdProdOrder);
TransFnshdProdOrderRtngLine(FnshdProdOrder);
TransFnshdProdOrderComp(FnshdProdOrder);
TransFnshdProdOrderRtngTool(FnshdProdOrder);
TransFnshdProdOrderRtngPersnl(FnshdProdOrder);
TransFnshdProdOrdRtngQltyMeas(FnshdProdOrder);
TransFnshdProdOrderCmtLine(FnshdProdOrder);
TransFnshdProdOrderRtngCmtLn(FnshdProdOrder);
TransFnshdProdOrderBOMCmtLine(FnshdProdOrder);
TransFnshdProdOrderLedgEntry(FnshdProdOrder);
-Check in the Database=>Information=>Tables how many records in total there are.
-It might also a good idea, to disable the secondary keys (except the ones needed for the upgrade) in these tables, then launch the upgrade, then restore the secondary keys. This is a method that can be used on all tables to gain some (and somethimes a lot) performance. The reason is that maintaining 10 keys record-by-record takes a lot more time then just rebuilding the keys from scratch when all records are in the table.Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!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