You may have seen my name connected with a lot of questions relating to upgrade procedure. I have started this thread in an attempt to encourage anyone who has any experiences with upgrades to post issues, solutions, hints, tips or any other information that you may have encountered or come up with in the course of your upgrade. This should also help centralise the information for people who look for help in the future If you are going to post, it would be helpful if you could give a brief description of the system you are upgrading, e.g. version, size, degree of modification etc. Also, please say if your post is an experience, question, solution etc. Hopefully the more of us that post, no matter how simple, the easier this process may become.[;)]
When look at the database for each object you have modified you have to look at three objects 1) the object in the clients database 2) the object in the base system being converted from 3) the object in the base system of the new data base For each object you have to choose to either apply the changes between the clients system and the old base system to the new base object. Or the changes between the old base system and the new base system to the object on the clients system. this must be done on an object by object basis. Paul Baxter
when useing the data upgrade functions do a data only backup from the old system and restore it in a new clean data base. Rewrite the navision code for converting the data to fix any error you get because you have changed the tables. When you get an error, stop fix the update code save the new update FOBS and start again from scratch as the data will be damaged because of the error. Continue until you can run through the whole process twice with out getting an error. When you have the update fobs you are then able to do the upgrade on the customers site. Stop postings on the old database do a data only backup and run the update routeine (and don’t get any errors???). Import all the objects and start them off on the new database. If any thing goes wrong they can always still use the old database when you come back another day to try again. Paul Bater
These are some of the problems i have had. 1)We have decided to do all modification manually as the upgrade toolkit was too indescriminite for our needs. It is important to remember that it only sees code and merges that according to its own rules, it isn’t smart enough to see why you may have put changes in certain places so these may get overlooked. 2)If you get an error in objects regarding type library not being found or errors relating to the CDO objects then you need to make sure that you have XML 3.0 or higher and that you have set up outlook with the correct CDO objects. 3)The upgrade toolkit version 1.02 will not accept a database from 3.60 when the setup instructions ask you to create a new database. We used a 3.10 database. 4)If upgrading in a GB version use the GBUpgradeProcess word document instructions, not the W1 pdf file as you main reference as some references may be a bit confusing 5)We had significant trouble in upgrading the ML section. When undertaking this process, make sure you check the results carefully. For example, problems occurred for us with a field that conatined an apostrohy in its name. It treated everything from that point to the next apostrophy as text. 6)When running the codeunits that unload and reload data from the newly converted database, you may have trouble with the statusbar as it runs because the integers in the calculation are too small to handle very large databases. We removed the running of this statusbar to solve this. 7)When you have run codeunit 104050 you may get an error relating to the type ‘duration’. You need to recompile the codeunit for it to work properly. 8)In the GB version, Codeunit 358 is not used so don’t be surprised if you come across it as a blank/empty object. 9)The temp customer table created during the upgrade contains a field of that creates an invalid type error. Either change they type or just delete the field, i have been assured that it is not required. I hope these help. If anyone would like to add to them or point out inaccuracies then your comments would be much appreciated.
quote:
Originally posted by John Small 9)The temp customer table created during the upgrade contains a field of that creates an invalid type error. Either change they type or just delete the field, i have been assured that it is not required.
For those who care - The infamous field is # 6, its name is “Lead Time Calculation”, its caption is “No.”, its type and size are “code, 10”; in the actual customer table field # 6 is “Name 2” (text 30). Since “Name 2” is often unfilled, this masterpiece of fantasy might go undetected. [}:)]
quote:
Originally posted by John Small I hope these help. If anyone would like to add to them or point out inaccuracies then your comments would be much appreciated.
- Table 336 in NM 2.60 and table 336 in NA 3.60 are wholly different things. Table 336 in NM 2.60 is not used so the migration tool does nothing about it, but if the source database was once migrated from an earliest version the table might contain a blank record; that must be deleted to prevent an error. regards Anna
Hi, Just a small addition for those who are upgrading to 3.60 from an earlier non-English version. [:)] Codeunit 104045, which must be run on the not yet migrated database, there are two CALCDATE operations that contain the constant value -1D. You must change it in <-1D> or the codeunit will crash. Regards Anna