Hello Dynamics GP Community!
In this article we will cover known issues that have been reported during Microsoft Dynamics GP upgrades, along with the available resolutions and workarounds.
Before beginning any upgrade, we highly recommend:
- Reviewing all upgrade documentation
- Reviewing known issues that may apply to your environment
- Performing a complete test upgrade before upgrading production
A little preparation can significantly reduce downtime and help avoid unexpected issues during your upgrade project.
The following issues have been encountered during previous Microsoft Dynamics GP upgrades. We will continue to update this post as additional issues are identified.
ASIEXP86 Table
During an upgrade to Microsoft Dynamics GP 2018 R2 or later, you may encounter an error regarding the ASIEXP86 table.
To work around this issue:
a. Make a copy of the ASIEXP86 table from the DYNAMICS system database.
b. Delete all records from the ASIEXP86 table.
c. Launch GP Utilities and rerun the upgrade.
d. After the upgrade is complete, delete all records from ASIEXP86 since the upgrade process inserts canned records.
e. Restore the records from the backup copy created in Step 1.
f. Insert the canned records using the following script:
INSERT INTO ASIEXP86
VALUES
(0,6,1,0,' ',' ','Deposits on Unposted Sales Transactions* ',1,1,1,0,22600,22600,0),
(0,6,1,0,' ',' ','Deposits on Unposted Sales Transactions* ',2,1,1,0,22601,22601,0),
(0,6,1,0,' ',' ','Deposits on Unposted Sales Transactions* ',3,1,1,0,22606,22606,0),
(0,6,1,0,' ',' ','Deposits on Unposted Sales Transactions* ',4,1,1,0,22637,22637,0),
(0,6,1,0,' ',' ','Deposits on Unposted Sales Transactions* ',5,1,1,0,22638,22638,0),
(0,6,1,0,' ',' ','Deposits on Unposted Sales Transactions* ',6,1,1,0,22787,26767,0),
(0,6,1,0,' ',' ','Deposits on Unposted Sales Transactions* ',7,1,1,0,22681,22681,0),
(0,6,1,0,' ',' ','Deposits on Unposted Sales Transactions* ',8,1,1,0,22683,22683,0)
This issue should be fixed with the release of the Microsoft GP 2018 R2 January 2019 hotfix.
This issue was corrected in later releases but may still be encountered in upgrade scenarios from older installations.
Account Framework Table Conversion
Several tables that contain account framework information are validated during the upgrade process.
If the account framework tables in the company database do not match the SY003001 and SY00302 tables in the DYNAMICS database, the upgrade will fail.
Run the Account Framework Validation script from the upgrade guide before upgrading.
If results are returned, please work with your partner or contact technical support to discuss options for those tables. We do have other account framework tables that can be changed, but these are a few of the main tables checked when it comes to account framework.
- GL10110
- GL10111
- GL70500
- GL70501
- GL00100
- GL00201
- IV70500
Budget Date Records in Analytical Accounting
The AA Budget Tree Balance table (AAG00904) contains budget records used by Analytical Accounting.
If budget records exist in AAG00904 but corresponding records do not exist in AAG00500 (aaDateSetup), the upgrade may fail with the following error:
AAG00904 135 [Microsoft][SQL Server Native Client x.x][SQL Server] Cannot insert the value NULL into column 'YEAR1', table 'xxxx.dbo.AAG00904'; column does not allow nulls. Update fails.
Validate and correct Analytical Accounting budget records before upgrading.
Database Compatibility
If you are migrating to a new SQL server in addition to the upgrade, you can restore your database to the new SQL server and start your upgrade. Please refer to KB 878449 for the steps covering migration to a new SQL server.
Once the database are restored to the new SQL server, you must change the database compatibility.
a. In SQL Server Management Studio, right-click your database and click properties.
b. Select Options on the left side list.
c. Change the compatibility level to match the version of SQL server you are running.
Purchase Order Tables
The upgrade may fail if detail records exist in:
~ POP10110
~ POP30110
without matching header records in:
~ POP10100
~ POP30100
Run the Invalid_Records_POTables script from the upgrade guide prior to upgrading. If results are returned, either:
a. Delete orphaned records
b. Run Check Links in your current Dynamics GP version
before proceeding.
Server Drop Down List Blank
When launching Microsoft Dynamics GP, the server drop down list may be blank. The server drop down is the ODBC DSN that is required by Dynamics GP in order to connect to your SQL server databases.
If the ODBC DSN is an older version or a 64-bit DSN, it will not appear in the list. Please make sure you have a 32-bit ODBC DSN created using Native Client 10.0 or newer driver.
Workflow Documents Must Be Final Approved
If you use Workflow for:
- GL Batches
- PM Batches
- RM Batches
- Purchase Orders
- Vendor Approvals
- Credit Limit Overrides
- Sales Quotes
- Employee Onboarding, etc.
all workflow documents must be fully approved before running the upgrade. Pending workflow documents will cause GP Utilities to stop and generate a report identifying the documents requiring approval.
Microsoft Dynamics GP Utilities Stops Responding
When you launch GP Utilities for the upgrade, most of the processing is performed on the SQL server.
If you happen to take focus away from GP Utilities, it may appear to stay white and show "not responding". Please do not close out of Utilities; the upgrade is still running - give the upgrade time to continue working.
If you feel the upgrade is hanging or locked up, please start a SQL Server Profiler trace to review activity.
Overlapping Fiscal Periods
When you launch GP Utilities to start the upgrade, if you have overlapping fiscal periods it will hang on the Multicurrency Setup Master table. Run the script below to determine if you have an overlapping fiscal periods and correct the periods prior to starting the upgrade process.
SELECT DISTINCT a.YEAR1,
a.PERIODID,
a.PERIODDT,
a.PERDENDT
FROM SY40100 a
JOIN SY40100 b
ON a.PERIODID <> b.PERIODID
AND a.PERIODDT <= b.PERIODDT
AND a.PERDENDT >= b.PERIODDT
AND ( a.PERIODID <> 0
AND b.PERIODID <> 0 )
ORDER BY YEAR1,
PERIODID
Payables Document Attachment Errors
If you have duplicate Attachment_ID values for Payables Transaction record and a Payables Transaction History record in the CO00104 and CO00105 table you may immediately ecounter an error.
The following statement during the upgrade causes this issue:
IF EXISTS (SELECT *
FROM dbo.sysobjects
WHERE id = Object_id(N'[dbo].[CO00104]')
AND Objectproperty(id, N'IsUserTable') = 1)
UPDATE CO00104
SET BusObjKey = Replace(BusObjKey, '0\PM\Payables Transaction History', '0\PM\Payables Transaction')
WHERE BusObjKey LIKE '%0\PM\Payables Transaction History%'
The error occurs when the upgrade attempts to update an BusObjKey value of "0\PM\Payables Transaction History\XXXXXXXXXX" to be "0\PM\Payables Transaction\XXXXXXXXXX". When it does this, the records with the same BusObjKey and Attachment_ID values can result in a duplicate records causing a primary key error that is visiable in the DEXSQL.LOG.
You can run the following script to workaround this issue:
The scripts will compare the BusObjKey and Attachement_ID for any potential issues and will create a cleanup script in the result tab.
Note: As always, ensure that you have a full working backups of your system and company databases before running the generated cleanup script. The script identifies what records are potentially going to cause a duplicate error - you can then make a decision to use the generated script to remove these records.
EHW20200, EHW30200 and EHW40200 Table Errors
We have found an issue with the Dynamics GP upgrade code which causes the EHW20200, EHW30200 and EHW40200 table to fail an upgrade if there is any data in these tables at all. These tables are part of the Employee Health and Wellness module (Prod ID 4955), which is one of the four modules that make up the Human Resources and Payroll Suite.
The issue is when the upgrade attempts to insert the data back into these tables, which both receive a new INACTIVE and EHW_Discount column added - it is trying to put the data back into the temp table where the data already exists instead of putting the data back into the newly upgraded tables.
If you run into this upgrade error you can get around this by running the steps below:
Make backups of the three EHW tables by running the following scripts against any company databases failing the upgrade:
SELECT * INTO EHW20200BAK FROM EHW20200
SELECT * INTO EHW30200BAK FROM EHW30200
SELECT * INTO EHW40200BAK FROM EHW40200
Run the following scripts to drop the original tables.
DROP TABLE EHW20200
DROP TABLE EHW30200
DROP TABLE EHW40200
Use the script to re-create the three EHW tables at the correct version to include the new INACTIVE and EHW_Discount columns. This script will also re-create the dexterity procedures for each table to recognize the new columns.
Run these scripts against any company failing the upgrade to restore the data back from backups created in step 1.
Run the following script that will update the system table to mark the three EHW tables upgraded.
UPDATE DYNAMICS..DU000030
SET Status = 0,
errornum = 0
WHERE PRODID = 4955
AND fileNumber IN ( 1, 2, 3 )
AND Status = 135
Helpful Resources
Before beginning your upgrade, review the following Microsoft resources:
Upgrading to Microsoft Dynamics GP [Upgrading...soft Learn | Learn.Microsoft.com]
System Requirements for Microsoft Dynamics GP [System Req...soft Learn | Learn.Microsoft.com]
Microsoft Dynamics GP Resource Directory [Dynamics G...soft Learn | Learn.Microsoft.com]
Stay tuned for the next post in the Upgrade Blog Series:
Microsoft Dynamics GP Upgrade - Version Checks & Upgrades
In that post we will review version requirements, supported upgrade paths, and important items to validate before launching GP Utilities.
Until then, start planning, start testing, and remember:
The most successful Dynamics GP upgrades are thoroughly tested before production.
Happy upgrading!
Angela Eckman
Microsoft Dynamics GP Support Team

Like
Report
*This post is locked for comments