Upgrade from Nav 2.6 to MBS-Nav 3.7

mcurriemcurrie Member Posts: 39
edited 2008-09-17 in Navision DOS
I am currently in the process of upgrading from Navision 2.6 to MBS-Nav 3.7. I have done the prep work and moved all of the customizations from the old 2.6 to the new 3.7 objects.

I have just started the data migration portion of the project and have run into some issues.

First of all, the upgrade manual that I have been using is not the most up to date verision I don't believe. If anyone knows where I might be able to find the most recent version please send me a link.

The real issue I am running into is this error message:
"Internal Error 1355 in Module 19"

When I get this message I am attempting to run codeunit 104045 - Upgrade 3.70 Step 1. The codeunit appears to be hanging while sorting through records on the item ledger entry table. I believe the message has something to do with DBMS Cache memory but I tried to increase this and it still fails (eventually). The next thing I thought of was to create a new key on the table but since I'm not sure what is happening I'm not sure what key to create/set.

If anyone has any idea's please let me know.

Thanks,
Matt

Comments

  • RobertMoRobertMo Member Posts: 484
    This message is realted to small letters using in code field (that allaows only capitals). Often apears during Navision backup. If data is inserted code fields through Navision it is properly capitalized, but when inserting from outside apps this doesn't happen and no error is shown at that time. This later causes troubles.

    There are options:
    - if entering data from outside, run the table, scan the code fields and capitalize manually if necessery
    - during objects upgrading process some fields are likely to be changed from text to code.
    - looks like the problem is in T32 that is split to 2 tables in 3.70. check those 2 fields
    - ?

    any luck ?
               ®obi           
    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  • mcurriemcurrie Member Posts: 39
    Thanks for the info but still no luck...

    -checked code fields to ensure all entries a capitalized
    -I did have one field that changed from text to code but I managed to fix that issue and move on

    Any other idea's?
  • RobertMoRobertMo Member Posts: 484
    the same error ? did you check all companies ?
    is it possible to change the code field back to text and you will fix it back after migration (if it helps) ?
               ®obi           
    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  • mcurriemcurrie Member Posts: 39
    Yep. The same error.

    The funny thing is we have three companies setup in the database that we are upgrading. This particular codeunit must be run for each company during the upgrade process. The first two companies ran fine but they are consulting portions of our business and do not have hardly any item ledger transactions. The third company is manufacturing based and currently has close to a million I/L transactions. When I run the codeunit for the third company it gets to about 10% and then search's the I/L table for several hours before erroring out. The last time I ran this codeunit I received another error in addition to the first error. This one read:

    "There is insufficient memory (stack) to execute this function."

    "This can be due to the way that recursive funtion calls are used in the program. Contact your system manager if you need assistance."

    I know it is something simple I'm missing...Looks like I'm going to be doing a few hours of debugging!!
  • RobertMoRobertMo Member Posts: 484
    for the first error:
    Do you have the same collations as original data ?

    The second error appears when a function is recursively called many times and then consumes all the memory. try to run on computer with most memory available.
               ®obi           
    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
  • SavatageSavatage Member Posts: 7,142
    That error has been a nightmare for many people prior to 3.6 - i thought it was fixed in the newer versions. A few Hotfix's are our there for this error for pre 3.6. you can do seach on the forum for 1355.

    Anyway....

    try doing you work on a client instead of the server. copy the database to you local hard drive (hopefully it's not too huge). I have been able to bypass this error when my database is local & not on the server.

    worth a shot.
  • mcurriemcurrie Member Posts: 39
    The first thing I did was move the database off the server and started running it locally. It actually ran for two days before the error reappeared once I started running the DB locally.

    Have you guys had any experience splitting a database? Can you split a native Navision database? And...lastly, does it have a huge impact on performance?

    I also asked my NSC about this problem and haven't heard back in a week or so...

    Thanks again for the help!
  • mcurriemcurrie Member Posts: 39
    Just a note for anyone who is interested...

    Problem solved..and it was something simple just as I suspected.

    There is a trigger that runs within this codeunit which sorts through the item ledgers looking ledger transactions with bins attached to locations. The problem was that when you search through 1mil transactions and you haven't sorted the table on the correct key it tends to take several days. The codeunit had been running for 6 days when I finally figured out what was wrong. I added a new key to the I/L table, inserted it into the trigger and it ran through the codeunit in about 20mins.

    On to the next issue...

    Thanks again!!
  • mromeromromero Member Posts: 20
    Hello mcurrie,

    Please, could you tell me the changes that you made to improve speed in the migration process?

    Thanks a lot.

    Miguel
  • mcurriemcurrie Member Posts: 39
    Hi Miguel,

    This was a long time ago but I'll try my best to remember. I believe it was Codeunit 104045 and the trigger was either UpdateBin or UpdateWarehouseEntry. In there you will find that it searchs through item ledger entries to identify those records that contain a bin. Then it inserts a warehouse entry based on the record found. The problem is the key in which the item ledger entry table is set on.

    Sorry thats the best I can do. We have upgraded to 4.01 since then and I no longer have any of the customized upgrade objects.

    Take care,
    Matt
  • mromeromromero Member Posts: 20
    Hello again Matt.

    Thanks a million for your effort. I´ll try to find out the trigger and apply your solution. I hope it improve the speed becouse it is spending DAYS.

    I´ll tell what happend at last.

    Take care you too.

    Miguel
  • mromeromromero Member Posts: 20
    Hello again,

    Finally nothing seems to work, it is spending an amazing amount if time to complete the "Transfer Data" task. :(

    I have done these changes, following the recomendations of users:

    1.- Add keys "Item No., Serial No." and "Item No., Lot No." in table 32.

    2.- Change "DBMS Cache" in "Tools -> Options" to value 500000

    3.- I have read codeunit 104045, that is containing in "Upgrade260400SP3.1.fob", but nothings seems to be wrong.

    4.- I have changed the refresh times in methods "Update" and "UpdateWindow" in table 104037 (State Indicator).

    Remember that I´m still in Stage 1, moving the data to temporary tables.


    Anybody can help me in other way? :cry:

    Thanks in advance.

    Miguel.
Sign In or Register to comment.