Hi, Can you please post your experiences (good and bad) if you have done a complete upgrade from NF2.50 or NF2.60 to Attain 3.10.A.[:)] We are trying to upgrade a 2.60 which has quite a few customizations in it to Attain 3.10.A. We have followed all the documentation but we are having a lot of trouble importing the text merged file from the Navision Developers Toolkit. [:(]We have almost come to the conclusion that it is easier to make manual changes straight into a 3.10.A database having compared standard 2.60 objects with the customised 2.60 objects first.[:(!] It appears that the official documentation probably works fine upgrading standard systems to standard systems but as soon as any customization is involved it fails any of the automatic procedures available.[V] Thanks in advance RPC
I believe the hardest parts of the upgrade process are: #1. The merging of customized objects from previous version to 3.10 #2. The customization of the upgrade toolkit codeunits and tables to accomidate upgrading a custom solution. I’ve found that I like to import all the table objects that overlap for the custom table object IDs only into the Developer’s Toolkit. It takes up a lot less space in DT, and you won’t see all the hits on the Caption changes and all the other stuff that was just changed in Attain. So, if you have tables 36, 37, 110, 111, 112, and 113 customized, then I would export only those objects from the Base Previous, Base Attain, and Customer Custom databases. Add to this any of the 50000+ table objects from the Customer Custom database. Next, I use a combination of Developer’s Toolkit and a text comparitor to view where all the changes are to Forms, Reports, Dataports, and CodeUnits. CodeUnits I find are very easy to upgrade using the text comparitor. The reason I do this with both DK and the comparitor is because of any changes that may have been made in the Customer Custom database that didn’t get documented correctly or at all. This means less calls from the client wondering where Field X went off his Sales Order wink. The changes to the Forms, Reports and Dataports I’ll do right in an Attain database. I’ll bring in the tables that were merged in DK, and the new text file of the new CodeUnits, and then I’ve got my Custom Attain objects. Export a FOB of all the objects from the Custom Attain, and I’m all set. Customizing the Upgrade Toolkit objects is a bit trickier. It’s more of a trial and error approach that I’ve taken. I’ll run it and see what pukes during the upgrade steps, and I’ll have to go back into the objects and set up new fields, tables, and code so that all the custom data is upgraded appropriately. Then I restart the upgrade steps from #1 all over again, and keep my fingers crossed. Sometimes I haven’t needed to worry about certain custom fields to be upgraded. I have also been known to take a few customizations from Financials that had corresponding Attain fields newly created in the base product and shove the data in. You always have to take it “case by case”. If I can be of any more assistance on a specific topic or element of the Upgrade Toolkit, please feel free to contact me again!
Hi Robin, If you follow all the Navision rules when developing then the upgrade is simple. Unfortunately most people don’t, so it isn’t. You really need to concider the Attain upgrade for what it is, … the implementation of a brand new system. Everyone upgrades differently. When I started, there where no tools, so I do everything manually, people newer to Navision will use the tools, simply because they are there now. The biggest problem wihtt he merge tool, is that it just merges code. It has no idea of the underlying business principles. If you have written a modification to handle serial numbers, and now that is a feature of Attain, then no amount of merging is going to give your client the correct solution. You need to try the differnt methids, and stick with the one you are comfortable with.
Hi, I am a colleague of Robins and would just like to ask for a bit of clarification on your very helpful postings [:)]. Kristopher - The main thing is where you say
CodeUnits I find are very easy to upgrade using the text comparitor.
I’ll bring in the tables that were merged in DK, and the new text file of the new CodeUnits
We would like to know how this is accomplished. Is it using word or similar to open two text files in separate documents and running a compare function or do you have a specific program? Your second quote (above) implies that you have a way of ‘creating’ a new text file ready for import. Is this done through a lot of laborious copy/paste action or is there a better way? I have a feeling i may be searching for some sort of developers utopia but any further advice would be greatly appreciated. Thanks again to you both for your help so far [:D] John
Hi churchil, As you can see, there are many approaches being followed & the best is upto you to decide depending on the customizations in 1.Base Area & 2. Custom range. If you ‘ve good documentation of changes, then the first thing that i do is: 1. go thru’ all the functional changes made(customization) to decide if it’s required or not? 2. Use NDT to identify changes to Tables. 3. In new database bring the customizations(Yes, Manually). Helps to remove,renumber or improve upon earlier changes. 4. Later, check Form Level changes & re-do them. 5. Same is the case with Codeunits. But identify how it’ll affect in the new System. 6. Report level customizations. Above approach, yes tedious but nevertheless gives me full control on the whole process. I would prefer to put more effort earlier than get struck with Merge/Import,conflicts and waste lot of time troubleshooting the same. Do search discussion on NDT in another topic. It’ll be useful to you. Regards
I you just remember to read the Conversion Document (100 pages) You will not be totally lost. Also remember to Adjust Exchange rates, Adjust Item Costs/Prices BEFORE upgrading to Attain. Palle
Originally posted by John Small We would like to know how this is accomplished. Is it using word or similar to open two text files in separate documents and running a compare function or do you have a specific program? Your second quote (above) implies that you have a way of ‘creating’ a new text file ready for import. Is this done through a lot of laborious copy/paste action or is there a better way?
You can find text comparitors available on the net. At Kelar, we use a program called ExamDiff Pro, which we’ve found to be best for our purposes. It displays the two files in either horz. or vert. panels, and sychronizes both files so that a scroll in one scrolls the other exactly the same. It colour codes the differences found (which I find convenient!) and it streamlines the “copy and paste” activity to a single mouse click for copying whole sections of code. I stated before that I use it mostly for CodeUnits, but there’s nothing stopping you from exporting all your Navision objects (tables, forms, reports) to text format and comparing them in the comparitor. I would suggest using the process in the Upgrade Toolkit that strips the ID qualifiers from all your variables, so you get far fewer hits. You can find more information about ExamDiff Pro from their website at: http://www.prestosoft.com/examdiff/examdiffpro.htm
I have a feeling i may be searching for some sort of developers utopia but any further advice would be greatly appreciated.
Oh, we’re all looking for our utopia! lol For now, we’re just stuck with our normal day-to-day grinds!
Thanks again for your help - we’ll give that program a go too. At the moment we seem to be progressing along the right lines but we are still adopting a try everything approach to new ideas and seems to be working providing everything is broken down into manageable pieces. Even so any help is gratefully received. We also appear to have taken a wrong turn to said utopia [:)] and stumbled into some kind of underworld [}:)] esp. with 3.6 upgrades imminent!! Thanks again
Originally posted by John Small
We also appear to have taken a wrong turn to said utopia [:)] and stumbled into some kind of underworld [}:)] esp. with 3.6 upgrades imminent!!
Oh, don’t get me started on 3.60! hehe We’ve got several customers that we’ve started working with upgrading, and then after installing 3.10, they ask “So we’re all current now?”, and we have to say, “No, another version comes out next month…” They always roll their eyes and ask if they’re getting that one included. I think Navision is at a good point to hold off on new versions for a while, now that we’ve gotten to the point of having a whole Attain product with financials, manufacturing, and distribution. Plus no one knows what the software can do anymore with all the new functionality. sigh But, enough ranting from me for now… wink
Hi everyone, I have been reading everything I can find out here on upgrading… I seem to be have a unique problem. I am upgrading from 2.6 to 3.1. I followed all the instructions and now have 3 versions in the toolkit and am running the compare & merge. The one thing that maybe I did different from other people is that all 3 versions have all the objects from that version. Maybe I have too much to compare??? My computer keeps running out of Virtual memory in the middle of the process. I have a 1G processor, 256K RAM, 15G open space on hard drive and 2G virtual memory. Can anyone help???
Hi Kelly. You are right, you should only need the changed objects from the 2.60 version. Note however that the boolean field “changed” can be checked of in the object designer, so you have to be sure.
Kelly, From my rather limited but frustrating experiences in this area it would seem that you are more or less on track. I don’t think that there are any hard and fast rules for this. We were unsure of the Developers toolkit but have found using it in combination with manual changes is working ok. (so far…) From what we have done, as Petursson has suggested, we have used the toolkit to merge only the changed base objects on the assumption that the new version base units will continue to function as the previous ones before them and so will just take the place of the unchanged old version base units. We have also found it easier to deal with each object type in turn (forms,reports etc) otherwise we have been missing errors/unwanted changes because of the volume of information present. I imagine you will also be forced to do some things manually such as form design because the toolkit doesn’t always get it right especially with things like main menu customisation. Basically its all a bit trial and error often with the emphasis on the latter. I hope this is some help!!
HELP!!! We have just come up against the next obstacle in the process. Having got as far as compiling the 3.10 objects we have come to some errors with tables 6206 E-Mail Queue, 6215 Picture and 6232 Message Log Header. The problem is that it is indicating that we have some kind of xml automation server missing. What is it and where does it come from? Many thanks in advance.
Originally posted by Kristopher Plus no one knows what the software can do anymore with all the new functionality. sigh
Hey Kristopher, I don’t think you can speak for everyone when you say that no one knows… I hope that those of us that sell and install Attain do know everything about the product.
hi there, my experience with navision developer’s toolkit was so unsuccessfully and if you want a lot of problems, please use the tool. a few months ago i had to do a migration from (jurassic) NF2.0 to Attain 3.01A, it means, a lot of changes… i tried to use the navision developer’s toolkit and i find problems and more problems every time i tried to do anything. first of all, locate the tool. later, understand the manual because it hasn’t any structure or logical sequence; after this, i tried to make a test of this tool with a standard database (the demonstration database included in the cd) and i couldn’t pass from the first 5 steps… finally, looking at the time i was loosing and thinking that this tool needs a special treatment (one master in sillicon valley…) i made the migration “in spanish ways”… this means i used the merge tool included in NF2.60 cd, i compared the necessary databases and later i moved the developments to the attain database one by one. of course, when i thought everything would be ok, the migration crashed every time i follow the steps indicated in the manual, because some objects given in the cd aren’t ok. so, i had to repair this objects and later re-start the migration process… doing this, i could end the migration. so, if you could make the migration by “no-standard-ways” (i mean, mysterious ways), make it and you can win so many time. regards!
John Small, I solved teh XML Automation problem with this download: http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/766/msdncompositedoc.xml Just install on the machine that you are planning to compile all the objects on and you will be fine!
Originally posted by David Singleton Hey Kristopher, I don’t think you can speak for everyone when you say that no one knows… I hope that those of us that sell and install Attain do know everything about the product.
grin I stand corrected. I guess there is always a learning curve to ramp up the a new level of software, and I know that not everyone has made the journey yet, but I’m sure there are plenty of eager people that have!
Hi everyone, I finally got all my objects updated. I backed up & restored the live 2.6 fdb to 3.1, imported the objects from the compare/merge fdb (modified & unmodified 3.1 objects). Now I am trying to go through the upgrading of the data. I get all the way to step 16 (chapter 5 of the Upgrade toolkit documentation) but cannot run the codeunit 104048. It blows up and the error I get is: The ROUND parameter 2 is outside the permitted range. Has anyone had this problem?
Hi Kelly, Me 2 faced the same problem. Spent a lot of time and finally solved it. The reason was : Inv. Rounding(LCY) or Inv. Rounding Precision field in GL Setup was blank. (The field is in table and not visible on form). Check it out. Regards