Upgrade to 3.7

Hi Everybody, We are currently on Navision 2.6 with native database option planning to upgrade to 3.7 with the sql database. We have lot of additions in terms of new objects and modifications done with existing system and i hope the upgrade tool will take care to convert these objects to 3.7. Can somebody please brief their experience on similar upgrades? Also we are planning to move all our clients terminals to Win XP. We currently use Win2k server with mix of win2000 and XP clients. Precisely we will finally have win2k server with XP clients. Please advice if this combination works well with navision 3.7 with sql database? Thanks for your comments on the above. Best regards, Anu

Hi, I have just completed testing a native database upgrade from 2.60 to 3.70. I used the Navision Developer’s Toolkit 1.03. The database was not heavily modified, however there were a number of code-units that had been written from scratch that required upgrading. My overriding feeling on the toolkit is that I wish I hadn’t used it for creating a merged version; HOWEVER I think it is very useful for comparing two versions i.e. standard 2.60 with your customized 2.60 so you can identify all the changes properly! Completely bespoke Code-unit Problems: The tool will not replace references to department with “Global Dimension 1 Code” or “Shortcut Dimension 1 Code”. Customized “Standard” Code-unit problems: The code merge was hopeless at getting additional lines of code in the correct place in merged objects. A number of codeunits have change significantly due to the introduction of item “Value Entries” and the new dimension functionality. Customized Stock Reports: Item reports have changed significantly due to the introduction of item “Value Entries”. Table problems: A number of tables that had not even been customized had errors introduced into them by the tool. For example Table 21 has a long calculation formula on the amount field, the exported text object had erroneous commas inserted into the formula, which prevented it from compiling, and there are a few other tables that had the same problem. Also I had documentation in the documentation trigger of table 81, for some reason the exported object had a text line that was too long for the compiler and fin.exe crashed every time I tried to compile it. You will need Column 9 of table 99003606 increasing from text 80 to text 250 in the toolkit database in order for you to view the C/AL for certain tables. This problem has been reported to the service system, they can send you a fixed version of the table if it isn’t already in a hotfix. To summarize, I found the toolkit doesn’t work as good as it looks if you use it to create a merged version. The trickiest part of the conversion was handling Value entries and dimensions. And expect some errors from the toolkit!! Good Luck![:)]

I agree with Jon. Another problem i found with the Developers toolkit is that on the newly merged version some of the tables didn’t have any keys, didnt’t matter if the merge reported conflicts or not on those tables. On one Table 32 “item Ledger Entry” it kept screwing up the “Sumindexfileds” on the keys with all sorts of weird and wonerful values.

Hi Anu, If you seach the forums under ‘upgrade’ you should find a number of threads that will give you a fair bit of information. Although i haven’t upgraded anyone to 3.7 yet i have completed a number of conversions to attain from various versions of Financials. In general we have found that the upgrade/merge tool isn’t really the best option. It is extremely indescriminate when dealing with cutomised standard objects. Although laborious, we have found that the best way is to use the ‘compare two versions’ tool in the toolkit. We used it to compare the database being upgraded with a standard (cronus) database of the same version. We then took the changes and replicated them manually in the new version. This was also useful as it allowed us to make any changes/improvements to the customisation as we worked. As a word of warning, the process will vary in time depending on levels of customisation to standard objects. Take a look at some of the previous postings on this site using the search function and they should hopefully help you along a bit. Good luck [;)]

Thanks a lot for your replies. From your conversation what i feel is to do it manually using ‘compare two versions’ tool in the toolkit. Apart from the version upgrade we are plaaning to convert the native database to SQL database. Some comments on this also would be higly appreciated. Thanks once again… Best regards, Anu

Hi First i would make sure the upgrade to 3.70 is all ok. Converting to SQL should be a lot easier[:)]. 1. Backup the Database (Keep Safe). 2. Import migrate.fob from the CD. 3. Run the migrate codeunits. This checks that the data is valid to SQL Server-specific demands, and corrects the data. 4. Recompile all the objects. 5. Backup the database. 6. Create new database in SQL Server. 7. Restore into the new database. I hope this helps[:)]

When creating the SQL database, make sure you choose the right collation on the Collation tab. The right one meaning the one that matches what you need in your language and case/accent sensitivity. In 3.70 you can choose a Windows collation which more closely matches the OS opinion of the way characters are sorted and compared, and therefore gives better consistency with other apps. It also has a better shelf life than the SQL collations. Although it is possible to later change the collation, in 3.70, it is a time consuming task (processing time, not human time). (Needless to say, the database file and log file layout is your first priority for a production database).

Hi Stephen, Thanks for your tips. It would be definitely helpful for me going further with database conversion. Best regards, Anu

Thanks Robert. I understand and noted down your point. Best regards, Anu

Can someone email me a copy of migrate.fob? We have Navision Financials 2.00 and it has no migrate.fob on CD Thanks

Michael it works the other way, the upgrade tools are on the latest CD, not the oldest CD. (Quite logical if you think about it). SOunds like one of those reports that once printed on paper don’t update to reflect the latest values.