Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
Here we are again, moving into that time of year where we're planning upcoming upgrades, such as the Fall 2020 upgrade of Microsoft Dynamics GP.
To try and help make this process of upgrading Microsoft Dynamics GP go as smoothly as possible, we've begun to put out our yearly Microsoft Dynamics GP upgrade blog series. This blog goes over how the upgrade of Microsoft Dynamics GP databases works and how to plan and prepare for an upgrade.
Hopefully at this point you have begun looking at our prior Dynamics GP Upgrade blogs that we've been releasing since Sept. 3rd:
--Microsoft Dynamics GP Fall 2020 Upgrade Blog Series Schedule
--Microsoft Dynamics GP Fall 2020 Upgrade: Upgrade Planning - Let's Get Started
--Microsoft Dynamics GP Fall 2020 Upgrade - Known Upgrade Issues
--Microsoft Dynamics GP Fall 2020 Upgrade - Version Checks & Upgrades
--Microsoft Dynamics GP Fall 2020 Upgrade: Lifecycle and Upgrade Services
If you haven't already looked through these blogs, I would highly recommend it if you are beginning to think about upgrading to the Microsoft Dynamics GP Fall 2020 update or any other GP upgrade.
I would also recommend looking through the 'System Requirements for Microsoft Dynamics GP' page and the 'Upgrading to Microsoft Dynamics GP' hot topic page as well, for the version of Microsoft Dynamics GP that you’re planning to upgrade to, as these will also be updated with the Dynamics GP information.
For example, if upgrading to Microsoft Dynamics GP 2018/18.#, any build, reference the following:
>>System Requirements for Microsoft Dynamics GP 2018/18.#:
>>Microsoft Dynamics GP 2018/R2 Product Download page / Dynamics GP 2018/18.# DVD:
>>Upgrading to Microsoft Dynamics GP hot topic:
>>Microsoft Dynamics GP 2018 Upgrade Instructions guide:
Database Upgrade - The Basics!
The upgrade to Microsoft Dynamics GP is the same upgrade process that we've had in prior versions, in that the database upgrade takes place through Microsoft Dynamics GP Utilities. The upgrade manual outlines the step-by-step process for this upgrade. Here are some of the basics.....
Along with the hot topics for ‘Upgrading to Microsoft Dynamics GP ####’ which states the required version/build of the application you must be on and upgrading to, you can also use scripts like this check for ‘old’ features that may have been installed previously:
--If coming from Dynamics GP 2010:
Select * from DYNAMICS..DB_Upgrade where db_verMajor <> 11
--If coming from Dynamics GP 2013:
Select * from DYNAMICS..DB_Upgrade where db_verMajor <> 12
--If coming from Dynamics GP 2015:
Select * from DYNAMICS..DB_Upgrade where db_verMajor <> 14
--If coming from Dynamics GP 2016:
Select * from DYNAMICS..DB_Upgrade where db_verMajor <> 16
--If coming from Dynamics GP 2018:
Select * from DYNAMICS..DB_Upgrade where db_verMajor <> 18
If any records are returned by these scripts, you’ll want to look at the PRODID value and compare that to your Dynamics.set file of your current Microsoft Dynamics GP install, to see if it’s a product you’re currently using, or a product that you plan to use on the new release in order to verify if it is at a required version/build in order to be able to upgrade.
We also have released a blog for this type of version error as well:
"Problem Ascertaining Version Information" error when installing or upgrading Microsoft Dynamics GP
***It is also recommended to export all modified forms and modified reports, along with VBA objects showing in the Customization Maintenance window (Microsoft Dynamics GP > Tools > Customize > Customization Maintenance) into a package file. This way, if there is an issue with upgrading the forms or reports dictionary files to the new version, the package file can be used to generate those dictionary files at the upgraded version.
Database Upgrade Tables:
The DU000010 table in the DYNAMICS/system database is the 'Utilities Update Files' table, meaning that it contains a list of tables that Utilities uses to determine which tables must be upgraded between the version/build of Microsoft Dynamics GP that you're currently on and the version/build that you're upgrading to. This table is populated via an .out file that is in the Microsoft Dynamics GP code directory you're launching Utilities from. Not every table gets upgraded with each service pack or hotfix released, and this table helps Utilities determine just that. GP Utilities uses the current and new version/build information in the DB_Upgrade system table to determine which tables require an upgrade and those that do not.
The DB_Upgrade table is also held in the DYNAMICS\system database and is the first table looked at when you launch Microsoft Dynamics GP Utilities. This is the main version table reviewed during the version check process discussed in the previous blog. Once the upgrade begins, Utilities will change the db_verMajor, db_verMinor and db_verBuild columns to the new version/build values that you're upgrading to. Not all features/modules in this table have the same version/build numbers nor do all features/modules get upgraded for each major upgrade, service pack or hotfix, so you may see different results for each of these. The db_status column will also change as the upgrade of the database progresses, beginning at 0 (zero) and moving up at each step, for example 23 indicates the tables conversion process is taking place and 53 is the Load Stored Procedures process with 54 being the 'wrapping up' step right before the upgrade process completes and changes the db_status back to 0 (zero). Once the database is upgraded successfully, the db_verOldMajor, db_verOldMinor and db_verOldBuild column values will be set to match those of the db_verMajor, db_verMinor and db_verBuild columns for each feature/module record, then it updates the DU000020 table.
The DU000020 table is another table that holds the version information for each feature/module per database that is installed. The versions in the DU000020 table will remain at the previous release until all tables in the database have upgraded successfully and the DB_Upgrade table is showing the same version/build for both versions and the db_status is 0 (zero) again. When a user launches into Microsoft Dynamics GP it is the DU000020 table information that is looked at for the DYNAMICS/system database and all company databases. This is different from Dynamics GP Utilities, which looks at the DB_Upgrade table instead.
**Note: If the upgrade of Microsoft Dynamics GP has completed on all databases, but the GP Utilities doesn't go back to the 'Additional Tasks' window, but instead shows a 'Upgrade These Companies?' window, with the company databases listed with green check-marks next to them, it usually means there is something in the DB_Upgrade table that Utilities sees, that it doesn't know how to handle. This could be a version from a prior install that is too old to upgrade and isn't installed, or something like that.
The duLCK table is used by Utilities to put a lock on a database while it is being upgraded or used in the upgrade process. This prevents users from logging onto the database during the upgrade process and/or making any changes to it. Once Utilities has completed the upgrade of the database, it will remove the record thus releasing the lock on the database. If Utilities is shut down or closed improperly, for example if the machine reboots or Utilities is killed through Task Manager, this record may remain in the duLCK table and when you re-launch Utilities, there will be a 'padlock' symbol next to the database symbolizing that the database is locked and you'll need to close Utilities, remove this record and then re-launch Utilities again before continuing with the upgrade of this database.
Lastly, is the DU000030 table, or Utilities Fail List table. When Utilities starts upgrading the tables within each database, it looks at the DU000010 as mentioned above to see what tables need upgrading. For every table that GP Utilities attempts to upgrade, whether successful or not, a record is inserted into the DU000030 table with a status for the upgrade. The 'Status' column shows which tables failed to upgrade and which were successful. Some common Status values for this table are:
0 - The conversion ran to completion without error.
2 - The table being converted or deleted was not found.
15 - The table was already converted since the table's structure matches the destination table definition.
25 - The path to the table could not be determined.
70 - Script Error. An error occurred while running a script. **Normally, this error is a result of another table causing this table to fail**
135 - An error occurred, and the table was renamed back to its original name and structure containing any data within it.
***The DU000030 table, for this reason, should always be empty before you launch Utilities for the first time on an upgrade of Microsoft Dynamics GP, whether it be a major version upgrade, service pack, hotfix or any other update that changes the database version information.
Before launching Utilities to upgrade the DYNAMICS/system database, make sure this table is empty, otherwise it can potentially cause errors with the upgrade by skipping tables during the upgrade process.
You can empty the DU000030 table by running this script, before you launch Microsoft Dynamics Utilities for the first time to begin the upgrade of the GP databases:
***NOTE: The 'Microsoft Dynamics GP - Upgrade Troubleshooting' blog, being released on Sept. 17th, will discuss in more detail how to troubleshoot errors during an upgrade of Microsoft Dynamics GP.
Server vs. Client/workstation - Where should you upgrade?
You can launch Microsoft Dynamics GP Utilities from the server or from a workstation, so because of this, you are not required to install Microsoft Dynamics GP on the SQL Server. The upgrade can be launched from a server or client workstation installation. The only difference may be a slight slowdown as Utilities communicates with SQL Server back and forth, between the two machines, but this does not add much, if any, overhead however.
Upgrading all companies at once vs. one or a couple at a time:
Upgrading all company databases at the same time is recommended but doesn't make much difference as far as Utilities is concerned, as it will upgrade each database in the same manner regardless. If you choose to upgrade all company databases at the same time, which is default, Utilities will run through all company databases' upgrade process, one after the other, and won't stop until either all company databases have been upgraded successfully, or an error occurs on one of the databases, that requires troubleshooting to move forward.
If you choose to upgrade one or specific company database(s) at a time, Utilities will upgrade those company database(s) and then once it completes, it will go back to the 'Additional Tasks' window in Microsoft Dynamics GP Utilities and you will need to close Utilities and re-launch it in order to select other remaining company database(s) to upgrade next or it will show an error message if one should be found.
Using a U.S. and another install of a different region/localization:
You may be using both a 'U.S.' install of Microsoft Dynamics GP as well as another install of Microsoft Dynamics GP with a different region/country selected, such as 'UK/Ireland'. We frequently see this done because with different regions selected, comes different additional products you can install with Microsoft Dynamics GP. For example, we don't have the option to install 'Canadian Payroll' on a 'U.S.' install of Microsoft Dynamics GP, but we do have that feature available to us on a 'Canada' install of Microsoft Dynamics GP.
When we see a multi-country environment where we have more than one install of Microsoft Dynamics GP installed each with a different region/country selected, the recommendation is to run GP Utilities from either the 'U.S.' or other country/region install first and update those modules, then you'll also need to run GP Utilities for any additional instances, in order to update any country/region specific modules, until all modules and features are upgraded accordingly.
Continue to check back with our Microsoft Dynamics GP Fall 2020 Upgrade Blog Series Schedule to learn more about the Microsoft Dynamics GP 2018 R2 Upgrade!
Please click here to watch a video of running a Microsoft Dynamics GP upgrade: VIDEO!! VIDEO!!
Hopefully the upgrade blogs in this series will again help give you the information you need, as well as any needed troubleshooting steps, to have a stress-free upgrade implementation with Microsoft Dynamics GP, whether you're a seasoned veteran or a rookie new to the upgrade process and Microsoft Dynamics GP!!
Business Applications communities