Hello all! It's been quite a while since I've actually written anything of remote interest to anyone who follows my blog, but at the same time, you will be pleased to know that I've been quite busy in the consulting front, with upgrades, server migrations, complex multi-instance postings involving 10's of thousands of transactions, wrapping up some Field Service Automation projects, and the list goes on and on.
This time around I want to bring to the forefront, an issue I encountered updating from Microsoft Dynamics GP 2013 SP2 to Microsoft Dynamics GP 2013 R2 plus the latest service pack.
Background
My client requested a server migration to a new environment where they wanted to deploy Dynamics GP 2013 R2 web client (plus the latest service pack) and upgrade their relational database management system to Microsoft SQL Server 2014. This is something I'm absolutely comfortable with (for the most part) given also that my client was sitting at Microsoft Dynamics GP 2013 with Service Pack 2.
As it is customary with these types of request involving a server migration, I followed the very clear instructions outlined in KB article 878449 - How to transfer an existing Microsoft Dynamics GP, Microsoft Small Business Financials, or Microsoft Small Business Manager installation to a new server that is running Microsoft SQL Server. I have walked through this article more times than I care to mention and can pretty much recite the steps by heart.
During the Dynamics GP Utilities process on the system database, I kept receiving the error message:
"Microsoft Dynamics Utilities Install/Upgrade failed"
This seemed to be a recurring problem on the sySrsReports table during the system database update. Upon further inspection, I noticed the temp table created for the sySrsReports (sySrsReport_T) was still present and that dropping this table would allow Dynamics GP Utilities to continue processing the system database update to completion.
However, the company database updates were failing with the following error messages:
"The stored procedure GetBD_UpgradeStatus() of form duSQL Pass Through SQL returned the following results: DBMS: 12, Microsoft Dynamics GP: 0."
![]()
Upon clicking the OK button, the following error message would appear:
"The stored procedure UpdateDB_Upgrade() of form duSQL Pass Through SQL returned the following result: DMBS: 12, Microsoft Dynamics GP: 0."
![]()
The above two errors would reiterate a few times (5 or 6 to be exact) to finally produce the following error:
"The stored procedure getCompanyID() of form duSQLInstall Pass Trough SQL returned the following results: DBMS: 12, Microsoft Dynamics GP: 0."
![]()
And would come to rest with the error described at first. Now, I've done myriads of upgrades in my lifetime, but this one put me on a cliff for a while. The DEXSQL.LOG clearly did not show anything specific and the duinstall.log just showed execution messages ("Message encountered" messages) happening where the problem occurred.
In all fairness, the DEXSQL.LOG kept showing a "[Microsoft][SQL Server Native Client 10.0]Communication link failure" error which lead me to check the version of SQL Server Native Client I was running, which was version 10. I then upgraded to SQL Server Native Client 11.0 and nothing really changed.
I also realized the update was failing while attempting to create the table auto procedures for the wkPostingValidationState table. I then drop this table and its auto procedures and restarted the update in the hopes it would recreate the objects once more, but was not successful.
Suffice to say, I restored the system database and company databases in order to devise a different strategy.
The Solution
After tinkering with the installation, I decided to retrace my steps and realized that during the installation process, I chose to install Web Client Runtime Engine - after all this machine was the web server and would be running a Single Machine instance of Dynamics GP. I then decided to install the Dynamics GP client on the database server without the Web Client Runtime Engine and launch GP Utilities once more. The update process ran flawlessly without any errors!
I still cannot understand why the presence of Web Client Runtime Engine would have caused an error while updating a service pack, however I have to remind everyone of the official Microsoft stance: "the session host must only be used to perform very little administrative work".
It was good to finally get pass these issues and complete the update process for my client.
Please take a look at my GPUG webinar on upgrades at:
![]()
Mariano's Toolbox: Upgrading to Microsoft Dynamics GP 2015 for dummies
Until next post!
MG.-
Mariano Gomez, MVP
Intelligent Partnerships, LLC
http://www.intelligentpartnerships.com/
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
This time around I want to bring to the forefront, an issue I encountered updating from Microsoft Dynamics GP 2013 SP2 to Microsoft Dynamics GP 2013 R2 plus the latest service pack.
Background
My client requested a server migration to a new environment where they wanted to deploy Dynamics GP 2013 R2 web client (plus the latest service pack) and upgrade their relational database management system to Microsoft SQL Server 2014. This is something I'm absolutely comfortable with (for the most part) given also that my client was sitting at Microsoft Dynamics GP 2013 with Service Pack 2.
As it is customary with these types of request involving a server migration, I followed the very clear instructions outlined in KB article 878449 - How to transfer an existing Microsoft Dynamics GP, Microsoft Small Business Financials, or Microsoft Small Business Manager installation to a new server that is running Microsoft SQL Server. I have walked through this article more times than I care to mention and can pretty much recite the steps by heart.
During the Dynamics GP Utilities process on the system database, I kept receiving the error message:
"Microsoft Dynamics Utilities Install/Upgrade failed"
This seemed to be a recurring problem on the sySrsReports table during the system database update. Upon further inspection, I noticed the temp table created for the sySrsReports (sySrsReport_T) was still present and that dropping this table would allow Dynamics GP Utilities to continue processing the system database update to completion.
However, the company database updates were failing with the following error messages:
"The stored procedure GetBD_UpgradeStatus() of form duSQL Pass Through SQL returned the following results: DBMS: 12, Microsoft Dynamics GP: 0."
Upon clicking the OK button, the following error message would appear:
"The stored procedure UpdateDB_Upgrade() of form duSQL Pass Through SQL returned the following result: DMBS: 12, Microsoft Dynamics GP: 0."
The above two errors would reiterate a few times (5 or 6 to be exact) to finally produce the following error:
"The stored procedure getCompanyID() of form duSQLInstall Pass Trough SQL returned the following results: DBMS: 12, Microsoft Dynamics GP: 0."
And would come to rest with the error described at first. Now, I've done myriads of upgrades in my lifetime, but this one put me on a cliff for a while. The DEXSQL.LOG clearly did not show anything specific and the duinstall.log just showed execution messages ("Message encountered" messages) happening where the problem occurred.
In all fairness, the DEXSQL.LOG kept showing a "[Microsoft][SQL Server Native Client 10.0]Communication link failure" error which lead me to check the version of SQL Server Native Client I was running, which was version 10. I then upgraded to SQL Server Native Client 11.0 and nothing really changed.
I also realized the update was failing while attempting to create the table auto procedures for the wkPostingValidationState table. I then drop this table and its auto procedures and restarted the update in the hopes it would recreate the objects once more, but was not successful.
Suffice to say, I restored the system database and company databases in order to devise a different strategy.
The Solution
After tinkering with the installation, I decided to retrace my steps and realized that during the installation process, I chose to install Web Client Runtime Engine - after all this machine was the web server and would be running a Single Machine instance of Dynamics GP. I then decided to install the Dynamics GP client on the database server without the Web Client Runtime Engine and launch GP Utilities once more. The update process ran flawlessly without any errors!
I still cannot understand why the presence of Web Client Runtime Engine would have caused an error while updating a service pack, however I have to remind everyone of the official Microsoft stance: "the session host must only be used to perform very little administrative work".
It was good to finally get pass these issues and complete the update process for my client.
Please take a look at my GPUG webinar on upgrades at:
Until next post!
MG.-
Mariano Gomez, MVP
Intelligent Partnerships, LLC
http://www.intelligentpartnerships.com/
