Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 305 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Upgrading to NAV 2015 - some bonkers findings and some tips...
AdrianAkers
Member Posts: 137
Hi All,
I have spent a lot of time upgrading databases from NAV 2009 up to NAV 2015 and have found some findings and reviewed the Microsoft steps that you might find useful. I do not see these as documented by Microsoft, but such changes have helped us and can really speed up the upgrade process. I am referring specifically here to the Data Upgrade steps. SynchNAV-Tenant is a different issue altogether! My tips and findings are detailed below...
1) By default the Change Log is not turned off when running all of the data upgrade steps. So every system upgrade change is hitting the Change Log if you are logging that table. I have tested it here and proved it in my office. This could be more than doubling the size of the Change Log for no really good reason, and also there is no COMMIT of this data so it is all held in memory on the server, hence why for big upgrades you might be throwing sill amounts of RAM into the server. TIP - Turn the change log off before running the Data Upgrade step.
2) Check your database as it is probably set to Auto Create and Auto Update Statistics. I have seen these processes kick in during the Data Upgrade step and seriously hamper performance. Consider turning this before the Data Upgrade step. You can always turn it back on afterwards (and run TSQL later to populate such information).
3) One of the Microsoft steps is to go through everywhere that a USERID is logged on any record in the system and add the domain name element to the front. Again you will need to make a call on this yourself, but my own view is that this is a bit crazy and not needed - unless in a primary key or part of a critical setup record. This code is part of Codeunit 104056 - Upgrade User Mgt. Notice that the code is clever and uses RecordRef and FieldRef based on table relations. Well this can give you an astronomical amount of data to update as a result (and it could all be hitting the change log as well)! I have modified my code to only update tables where this is really necessary in my solution. You don’t lose anything from this as you still have then the exact same data as you have today - your customer loses nothing - and you will need to decide if they really gain anything from updating all of this historical data with a domain name. Also there is a big flaw in this step. I have clients with the same user in multiple domains. The code can't work out which domain they were in at the time (obviously!), so how can it know what domain to add to the front now?! Ok it has that Temp Windows Login table in the upgrade steps, but this step does not work either where you have the same user working in different domains - which is actually quite a normal course of events and we see this all the time.
Hope this helps someone, somewhere and some point.
Ade
I have spent a lot of time upgrading databases from NAV 2009 up to NAV 2015 and have found some findings and reviewed the Microsoft steps that you might find useful. I do not see these as documented by Microsoft, but such changes have helped us and can really speed up the upgrade process. I am referring specifically here to the Data Upgrade steps. SynchNAV-Tenant is a different issue altogether! My tips and findings are detailed below...
1) By default the Change Log is not turned off when running all of the data upgrade steps. So every system upgrade change is hitting the Change Log if you are logging that table. I have tested it here and proved it in my office. This could be more than doubling the size of the Change Log for no really good reason, and also there is no COMMIT of this data so it is all held in memory on the server, hence why for big upgrades you might be throwing sill amounts of RAM into the server. TIP - Turn the change log off before running the Data Upgrade step.
2) Check your database as it is probably set to Auto Create and Auto Update Statistics. I have seen these processes kick in during the Data Upgrade step and seriously hamper performance. Consider turning this before the Data Upgrade step. You can always turn it back on afterwards (and run TSQL later to populate such information).
3) One of the Microsoft steps is to go through everywhere that a USERID is logged on any record in the system and add the domain name element to the front. Again you will need to make a call on this yourself, but my own view is that this is a bit crazy and not needed - unless in a primary key or part of a critical setup record. This code is part of Codeunit 104056 - Upgrade User Mgt. Notice that the code is clever and uses RecordRef and FieldRef based on table relations. Well this can give you an astronomical amount of data to update as a result (and it could all be hitting the change log as well)! I have modified my code to only update tables where this is really necessary in my solution. You don’t lose anything from this as you still have then the exact same data as you have today - your customer loses nothing - and you will need to decide if they really gain anything from updating all of this historical data with a domain name. Also there is a big flaw in this step. I have clients with the same user in multiple domains. The code can't work out which domain they were in at the time (obviously!), so how can it know what domain to add to the front now?! Ok it has that Temp Windows Login table in the upgrade steps, but this step does not work either where you have the same user working in different domains - which is actually quite a normal course of events and we see this all the time.
Hope this helps someone, somewhere and some point.
Ade
3
Comments