Upon launching, a freshly installed Dynamics GP 2010 client was throwing the error: “Microsoft.Dynamics.GP.Rtc.dll: QI for IEnumVARIANT failed on the unmanaged server. ” GP 2013 had previously been installed on this workstation.
The solution was to rename the Microsoft.Dynamics.GP.Rtc.dll file in the Add-ins folder by adding a “.bak” extension. This file is associated with Microsoft Lync and the Shoretel Communicator. If you’re not using those programs, you can safely bypass the file. After renaming, GP ignored the file and launched without error.
It was time for year-end payroll updates for Dynamics GP. I had applied the update for v. 18.281036 (KB4528419), and things were going fine until the GP Utilities tried to list the companies to be upgraded. Then everything hung up on this screen. Instead of a list of the companies to be upgraded, I got a dialog box with a gray background containing a single empty checkbox and a Next button.
I didn’t want to be too hasty. Sometimes the utilities might be slow to re-draw a screen, but SQL routines will still be chugging away in the background. I checked Task Manager, and it showed 10% CPU utilization for the task. I checked SQL Profiler, and there was plenty of activity in SQL. The thing was, it looked like the same activity over and over, and after about 90 minutes, I decided it was stuck in an endless loop.
After consulting with colleagues, we found another post that made reference to the Clear Companies script. That jogged my memory. Had I seem a reference to “TWO” in the SQL Profiler trace?
I ran a “Select * from SY01500” SQL query to fetch the list of GP companies, and sure enough, there was a reference to Fabrikam, the GP sample company. But the corresponding database named “TWO” did not exist in our SQL instance.
I ran the Clear Companies script, restored the databases, and tried the update again. This time it ran as expected.
In Dynamics GP, the following message came up when I tried to calculate the VAT report: “The input tax for this range hasn’t been entered. Do you want to continue calculating?”
To fix the error, I ran the following SQL script against the company database to find earliest transaction date on the return:
selectmin(Docdate) from TX30000 where Included_On_Return = 0
I found that the effective date needed to be set back to 30 Nov 2017 so that it pre-dated the earliest date included on the return. It appears that the VAT return was not run for Dec. 2017, so I ran it for both Dec. 2017 and Jan. 2018, and it completed without errors.