Microsoft Dynamics GP 2013 – Upgrade Troubleshooting

CONGRATS!! You have come a long way with us in the Upgrade Blog Series journey! You now know how to upgrade to Microsoft Dynamics GP 2013. Now let’s dig in and learn how to troubleshoot the upgrade if you happen to run into issues. The most common upgrade cases that we take on a daily basis include the following:

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 feature changes. The DU000010 table in the DYNAMICS database contains the list of tables that will be converted to Microsoft Dynamics GP 2013. You can run the script below to find the list of tables that are converted for each Microsoft Dynamics GP release:

Microsoft Dynamics GP 10.0Select fileOSName from DYNAMICS..DU000010 where CodeName like 'GP10%' or CodeName like 'Montego'

Click HERE to download the complete table conversion table list! You can also refer to the Microsoft Dynamics GP 2013 Software Development Kit (SDK) for detailed table changes from the prior release. The SDK can be installed from the DVD under the Tools\SDK folder.

If you are currently on Microsoft Dynamics GP 10.0 and are upgrading to Microsoft Dynamics GP 2013, the conversion scripts for both Microsoft Dynamics GP 2010 and Microsoft Dynamics GP 2013 will be run against your company database even though you are not installing the Microsoft Dynamics GP 2010 client application for the upgrade.

The key to troubleshooting the table conversion 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 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 RENAMEThe first step for every table that goes through the conversion process is a table rename. The current table must first be renamed before the new Microsoft Dynamics GP 2013 table is created. This is like making a “backup” of the table. The most common naming convention used to rename the tables is the following:

GL00100 >> G00100LSOP10100 >> S10100OP

As you can see from the above, the tables that start with 2 letters have the second letter placed at the end of the table. Those tables with 3 letters, have the second and third letter placed at the end. **TIP**When opening up the Dexsql.log for the first time to search for a table failure, 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 RENAMEA new primary key is created with the new Microsoft Dynamics GP 2013 table, therefore, the current primary key is also renamed. This does not necessarily mean the primary key is different from the previous release.

Dexsql.log Snip It – Rename Primary Key

3. New Microsoft Dynamics GP 2013 table is created: Key Word CREATEMicrosoft Dynamics GP 2013 Utilities uses the Dynamics.dic to create the new table in the required structure for Microsoft Dynamics GP 2013. 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 SELECTDuring the table conversion, Microsoft Dynamics GP Utilities may run select statements against the old renamed table, the newly created table or even completely different tables that the table conversion depends on. The selects 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 INSERTNow that the new Microsoft Dynamics GP 2013 table is created, Utilities must insert your records from the old table. This is the most common point of failure during the table conversion due to table structure issues. For example, if the old table is not in the correct structure, the insert will fail. Also, if the new Microsoft Dynamics GP 2013 table 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 DROPOnce the insert statement inserting all records into the new table from the old table is successful, the old renamed table is dropped.

Dexsql.log Snip It – Drop Table

Once a table upgrades successfully the Status is set to a 0 in the DU000030 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!

The best part of the upgrade is each step is tracked in the db_status column in the DB_Upgrade table. This allows Utilities to “remember” where it started and stopped. 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 if the upgrade fails. If the upgrade fails, you can close out of Utilities, fix the issue and launch Utilities again. Because of the number in the db_status column in the DB_Upgrade table, Utilities will pick right up where it left off. AWESOME!

Utilities also does a great job when individual tables fail. If a table fails to convert, Utilities will rollback the table conversion process and set the table in its original state. For example, if you are upgrading from Microsoft Dynamics GP 2010 and the GL00100 table fails to upgrade, the upgrade will rollback the process and place the GL00100 back to the 2010 version with all of your records intact. SUPER AWESOME! Again, this allows you to close out of Utilities, take the steps needed to fix the table and start Utilities again without restoring!!

Let’s Troubleshoot a Table Conversion Failure!

When the table conversion fails, the following window will appear in Microsoft Dynamics GP 2013 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.

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.

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 take to resolve this issue.Click HERE to download the sample scripts used in the Video.

On two tables: IV70500 and GL00201, I keep getting "an error and the temporary table did not get removed." with a recommended action: "Remove the temporary table at the database level". What is / are the temporary table(s)? is it the DU000010 or .DU000030 table? Or some other tables?