Very slow upgrade (manufacturing)

AlishaAlisha 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

Comments

  • krikikriki Member, Moderator Posts: 9,118
    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!


  • jbuerjbuer Member Posts: 1
    I ´ve had a simliar problem.
    In my case a item ledger entry with Number 0 was the problem.
  • AlishaAlisha Member Posts: 217
    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?
  • AlishaAlisha Member Posts: 217
    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?


    Thanks
  • krikikriki Member, Moderator Posts: 9,118
    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!


  • krikikriki Member, Moderator Posts: 9,118
    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.
    I took the upgrade 260-400 to check where something with finished production orders happens, but I don't find anything. Could it be that it is some localization?
    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!


  • AlishaAlisha Member Posts: 217
    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!
  • krikikriki Member, Moderator Posts: 9,118
    Alisha wrote:
    TransFnshdProdOrderLine(FnshdProdOrder);
    TransFnshdProdOrderRtngLine(FnshdProdOrder);
    TransFnshdProdOrderComp(FnshdProdOrder);
    TransFnshdProdOrderRtngTool(FnshdProdOrder);
    TransFnshdProdOrderRtngPersnl(FnshdProdOrder);
    TransFnshdProdOrdRtngQltyMeas(FnshdProdOrder);
    TransFnshdProdOrderCmtLine(FnshdProdOrder);
    TransFnshdProdOrderRtngCmtLn(FnshdProdOrder);
    TransFnshdProdOrderBOMCmtLine(FnshdProdOrder);
    TransFnshdProdOrderLedgEntry(FnshdProdOrder);
    -Check in these functions, if they use the correct key.
    -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!


Sign In or Register to comment.