mibuso.com

Microsoft Business Solutions online community
It is currently Sat May 25, 2013 12:15 am

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: Upgrade from Nav 2.6 to MBS-Nav 3.7
PostPosted: Mon Jun 07, 2004 8:13 pm 
Offline

Joined: Mon Jun 07, 2004 7:47 pm
Posts: 30
Location: Newmarket
Country: Canada (ca)
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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jun 07, 2004 11:12 pm 
Offline

Joined: Sun May 02, 2004 2:29 pm
Posts: 466
Location: Stäfa, Switzerland
Country: Switzerland (ch)
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           
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


Top
 Profile E-mail WWW  
 
 Post subject:
PostPosted: Tue Jun 08, 2004 3:27 pm 
Offline

Joined: Mon Jun 07, 2004 7:47 pm
Posts: 30
Location: Newmarket
Country: Canada (ca)
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?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jun 08, 2004 5:30 pm 
Offline

Joined: Sun May 02, 2004 2:29 pm
Posts: 466
Location: Stäfa, Switzerland
Country: Switzerland (ch)
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           
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


Top
 Profile E-mail WWW  
 
 Post subject:
PostPosted: Wed Jun 09, 2004 4:26 pm 
Offline

Joined: Mon Jun 07, 2004 7:47 pm
Posts: 30
Location: Newmarket
Country: Canada (ca)
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!!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jun 09, 2004 6:41 pm 
Offline

Joined: Sun May 02, 2004 2:29 pm
Posts: 466
Location: Stäfa, Switzerland
Country: Switzerland (ch)
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           
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


Top
 Profile E-mail WWW  
 
 Post subject:
PostPosted: Wed Jun 09, 2004 6:59 pm 
Offline
MVP Microsoft Dynamics NAV
Site Supporter

Joined: Fri Jun 06, 2003 9:01 pm
Posts: 6979
Location: L.I., New York
Country: United States (us)
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.

_________________
Harry Ruiz
http://www.cosmeticsolutions.com
http://www.autismspeaks.org


Top
 Profile E-mail WWW  
 
 Post subject:
PostPosted: Wed Jun 09, 2004 7:32 pm 
Offline

Joined: Mon Jun 07, 2004 7:47 pm
Posts: 30
Location: Newmarket
Country: Canada (ca)
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!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 17, 2004 9:02 pm 
Offline

Joined: Mon Jun 07, 2004 7:47 pm
Posts: 30
Location: Newmarket
Country: Canada (ca)
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!!


Top
 Profile  
 
 Post subject:
PostPosted: Tue Sep 16, 2008 1:46 pm 
Offline

Joined: Thu Nov 08, 2007 5:35 pm
Posts: 18
Location: Malaga
Country: Spain (es)
Hello mcurrie,

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

Thanks a lot.

Miguel


Top
 Profile  
 
 Post subject:
PostPosted: Tue Sep 16, 2008 2:29 pm 
Offline

Joined: Mon Jun 07, 2004 7:47 pm
Posts: 30
Location: Newmarket
Country: Canada (ca)
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Sep 16, 2008 7:11 pm 
Offline

Joined: Thu Nov 08, 2007 5:35 pm
Posts: 18
Location: Malaga
Country: Spain (es)
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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Sep 17, 2008 9:55 am 
Offline

Joined: Thu Nov 08, 2007 5:35 pm
Posts: 18
Location: Malaga
Country: Spain (es)
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum


Search for:
Jump to: