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
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Now that you know how to upgrade to Microsoft Dynamics GP 2013 R2, the next thing we’ll look at is how to troubleshoot any errors or issues that you may see during a database upgrade. The most common upgrade support cases for Microsoft Dynamics GP that we take on a daily basis include:
1. Version Check Issues – Check Out the Blog Again!2. Reports and Form Upgrade Issues – Check Out the How To Blog Again!3. Table Conversion Issues
Chris shared a great blog on version checks and Sarah shared a great blog on how to upgrade your modified reports and forms. Those blogs will get you on the right track for those areas. Check them out again for review!! In this blog, I will focus on the table conversion.
The table conversion is the step in the upgrade where a certain set of tables go through a conversion process for the required Microsoft Dynamics GP 2013 R2 feature changes. Not each and every table gets updated each time a database goes through an upgrade to a new version/build of Microsoft Dynamics GP.
Microsoft Dynamics GP Utilities uses the DU000010 table in the DYNAMICS/system database, which contains a list of table updates, and it uses the version/build that you’re starting from and then the version/build that you’re upgrading to for Microsoft Dynamics GP. Using that information, it gets a list of tables that need to be updated between the original and new versions. Sometimes one table can go through more than one update during a database upgrade.
You can run the scripts below to find the list of tables that are converted for each Microsoft Dynamics GP release:
Microsoft Dynamics GP 2013 R2 >> Select fileOSName from DYNAMICS..DU000010 where CodeName = 'GP12SP3'
Microsoft Dynamics GP 2013 Select fileOSName from DYNAMICS..DU000010 where CodeName = 'GP12'
Microsoft Dynamics GP 2010Select fileOSName from DYNAMICS..DU000010 where CodeName like 'GP11%'
Microsoft Dynamics GP 10.0Select fileOSName from DYNAMICS..DU000010 where CodeName like 'GP10%' or CodeName like 'Montego'
You can also refer to the Microsoft Dynamics GP 2013 R2 Software Development Kit (SDK) for detailed table changes from the prior release:
If you are currently on Microsoft Dynamics GP 10.0 and are upgrading to Microsoft Dynamics GP 2013 R2, the table updates mentioned in the DU000010 table for Microsoft Dynamics GP 2010, Microsoft Dynamics GP 2013 and Microsoft Dynamics GP 2013 R2 will all be run against your databases even though you are not actually installing Microsoft Dynamics GP 2010 client application for the upgrade.
The key to troubleshooting table upgrade errors is to first understand what happens to each table. You can then trace those steps in the Dexsql.log. The Dexsql.log is a tracing tool that will log everything that Microsoft Dynamics GP 2013 R2 Utilities is doing during the upgrade process. This includes the table conversion process itself. If a table fails during the table conversion, you can use the steps to find where the failure happened in the Dexsql.log.
Table Conversion Steps for Each Table
1. Table is Renamed: Key Word ‘RENAME’
The first step that occurs for a table going through an upgrade is that it gets renamed. This is done so that the new Microsoft dynamics GP table can be created. This is also important because it is like creating a backup of the table. An example of the naming convention that Dynamics GP Utilities uses to rename tables is the following: GL00100 >> G00100LSOP10100 >> S10100OP
As you can see with this example, the tables that start with 2 letters have the second letter placed at the end of the table. Those tables that begin with 3 letters have the second and third letter placed at the end.
**TIP: When looking at a Dexsql.log to troubleshoot a failed table upgrade error, always search on the renamed table. For example, if the GL00100 failed, you would start your search with G00100L to get to the start of the conversion process for that table.
Dexsql.log Snip It – Rename Table
2. Primary Key is Renamed: Key Word ‘RENAME’
The primary key for each renamed table is also renamed so that the new primary key for the new Microsoft Dynamics GP table can also be created. This doesn’t necessarily mean the primary key is different than the previous release. Dexsql.log Snip It – Rename Primary Key
3. New Microsoft Dynamics GP 2013 R2 table is created: Key Word ‘CREATE’Microsoft Dynamics GP Utilities uses the Dynamics.dic to create the new table in the required structure for Microsoft Dynamics GP 2013 R2. The primary key, secondary indexes, dexterity procedures and bindings are also created during this process.
Dexsql.log Snip It – Create Table
**NOTE: **The ‘CREATE TABLE’ process is a very long process. In the Dexsql.log, you will see the start of the process with the CREATE TABLE. The end of the table creation process will be several “Default bound to column” messages like the following:
4. Check structure of new table, old table and/or dependent tables if applicable: Key Word ‘SELECT’
During the table upgrade process, Microsoft Dynamics GP Utilities may run SELECT statements against the original/renamed table, the newly created table, and/or even completely different tables that the current table being upgraded depends on. The SELECT statements are to validate the table structure of one or more tables. Dexsql.log Snip It – Select Table
**NOTE: The ‘select’ statement can also be after the Insert statement as well
5. Records Inserted from Old Table to New Table: Key Word ‘INSERT’
After the new Microsoft Dynamics GP 2013 R2 table is created and verified as being correct. Microsoft Dynamics GP Utilities will then insert any records that were in the original/renamed table. This is an important point of failure during the table upgrade process because if the old/renamed table is not in the correct structure, the insert will fail. Also, if the newly created table for Microsoft Dynamics GP 2013 R2 is not in the correct structure, the insert will also fail. Dexsql.log Snip It – Insert into new Table
6. Renamed table is dropped: Key Word ‘DROP’
Once the INSERT statement finishes inserting all records into the new table without any issues, then the old/re-named table is dropped.
Dexsql.log Snip It – Drop Table
At the point of a table upgrading successfully and all data being inserted without issues, Microsoft Dynamics GP Utilities will set the Status for the table to a 0 in the DU000030 system table indicating the table was upgraded successfully
Dexsql.log Snip It – DU000030 insert indicating table upgrade success
The Beauty of the Upgrade – The db_status & Rollback! – You Don’t Need to Restore!
An important part of the upgrade process is that each step is tracked by the DB_Status column in the DB_Upgrade system table. This allows Microsoft Dynamics GP Utilities to ‘remember’ where it stated and left off for an upgrade. The DB_Status of 23 is the table conversion step. Since Utilities remembers where it left off, you do not need to restore the database(s) if the upgrade fails. If the upgrade does fail, you can close out of Utilities, fix the issue and then re-launch Utilities again. Because of the number in the DB_Status column in the DB_Upgrade system table, Utilities knows where it left off and will pick up from that step.
Microsoft Dynamics GP Utilities does a great job when individual tables fail. If a table fails to convert, Utilities will roll-back the table by deleting the new table and primary key, and then re-naming the old table and primary key back to their original name. For example, if the GL00100 table failed the upgrade conversion for any reason, Utilities would delete the new GL00100 table and primary key, and then rename the old G00100L table back to GL00100 along with its primary key. This way we don’t have to worry about losing any records in the upgraded tables and it allows you to close out of Utilities, fix any issues causing upgrade failures, and then launch Utilities again without needing to restore. Pretty AWESOME, eh?
Let’s Troubleshoot a Table Conversion Failure!
(A HUGE Thank You to Kelly Youells for this section and the Troubleshooting video below!!!)
When the table conversion fails, the following window will appear in Microsoft Dynamics GP 2013 R2 Utilities. Microsoft Dynamics GP Utilities will stop on the first company that fails. For example, if you mark to upgrade 15 companies and the 5th company fails, Utilities will not continue to upgrade the remaining 10 companies.
Steps to Troubleshoot a Table Conversion Failure
1. Don’t Panic!!The first step is to not panic when you see a Red X next to your company. Hopefully, you are running the test upgrade first so you have time to troubleshoot. If you are not running a test upgrade, this blog will help you get the issue resolve fast!
2. DO NOT Restore the company databaseAs mentioned above, Microsoft Dynamics GP Utilities remembers where it left off. All troubleshooting can take place at the point of failure and no restore is required.
3. Close out of UtilitiesWhen the Red X appears next to the company, close out of Microsoft Dynamics GP Utilities to start the troubleshooting process.
4. Determine what tables failedRun the script below in the SQL Server Management Studio to determine what tables failed. Pay particular attention to the errordes column. This column usually provides enough detailed information to start troubleshooting without even looking at the Dexsql.log.
SELECT b.fileOSName, a.fileNumber, a.PRODID, a.Status, a.errornum, a.errordes, c.CMPANYID, c.INTERIDFROM DYNAMICS.dbo.DU000030 aJOINDYNAMICS.dbo.DU000010 bON a.fileNumber = b.fileNumberAND a.PRODID = b.PRODIDJOINDYNAMICS.dbo.SY01500 cON a.companyID = c.CMPANYIDWHERE (a.Status <> 0 or a.errornum <> 0) and a.Status <>15
In this example, the following tables are failing:
5. Based on the results above, check the Known Upgrade Issues and Critical Upgrade Issues listsEven if you checked the Known Issues List and Critical Upgrade Issues prior to the upgrade, it is a good idea to check them if tables failed during the table conversion. Known Upgrade Issues listed in the Dynamics GP 2013 R2 Upgrade guide:
'Upgrading to Microsoft Dynamics GP 2013 R2' hot topic:
6. Based on the results above start troubleshooting! If the issue is not a Known Issue or Critical issue, start troubleshooting!The errordes column above can provide great direction to start troubleshooting. In this example, we are upgrading from Microsoft Dynamics GP 2010. Since the errordes column above references a table structure issue prior to upgrading, we know that we must investigate the table structure. Again remember, that each table is rolled back if it fails, therefore, right now the SOP10200, IV70500 and the GL00201 are set back to the Microsoft Dynamics GP 2010 version. All troubleshooting can take place right in the failed state. DO NOT restore the database!
CHECK OUT the VIDEO for the resolution to the table conversion failure above!! The video will walk you through resolving the issue and provide the troubleshooting steps that you can then apply to all future table conversion issues you run into on any table!
Click HERE to download the sample scripts used in the Video.
Please continue to check out our Microsoft Dynamics GP 2013 R2 Upgrade Blog Series Schedule for the remaining blogs!
Happy Upgrading and enjoy Microsoft Dynamics GP 2013 R2!!!
ResourcesHow to create a Dexsql.log
Business Applications communities