Month: August 2021

We’ve recently been implementing Microsoft Dynamics GP for a manufacturing company in England. When verifying that opening balances had imported correctly, the user reported that not all of the rows in Management Reporter were displaying an account description. A quick check around and I found a blog post from nJevity covering this exact subject.

Typically Management Reporter is run only to show posted transactions, but you can also set it to include unposted transactions. In this testing , we were returning both posted and unposted as we had imported the opening balances, but not yet posted them in case any changes were required.

The rows which included only unposted transactions did not display the account descriptions, but rows with even a single posted transaction did. As soon as the opening balances were verified and posted, all rows did display the account description. As the client would not usually be reporting on unposted activity, this was deemed a non issue.

During a recent upgrade of Microsoft Dynamics GP, the client supplied a link to be used for a repurposed Intelligent Edge section on the home page. However, once their Intranet site link had been added, users started getting a script error like the below:

Internet Explorer Script Error

An error has occurred in the script on this page
Line: 320

Char: 6

Error: The system cannot find the file specified
Code: 0
URL: file:///D:/Documents%20and%20Settings/gptestuser/Local%20Settings/Temp/1/tmp10.tmp
Do you want to continue running scripts on this page?

I wasn’t able to get a screenshot of the error at the time, and the above is taken from Microsoft KB article which covered this issue in Q31.

The solution is to create a UserData folder in each users %appdata%\Microsoft\Internet Explorer\. Once we did this, the error did cease to be displayed.

I recently did a Microsoft Dynamics GP upgrade for a client which included Management Reporter. During the upgrade of Management Reporter to the latest hotfix, we found that the upgrade of the legacy connector failed every time. We spent quite a bit of time looking into the problem and eventually got it to install correctly.

When legacy connector was first added, it was added using the FQDN of the SQL Server Instance (SQL01.example.com\GP), the upgrade failed every time we tried to use the FQDN, but when we switched to just the machine name (SQL01\GP), the upgrade was successful.

Management Reporter has been used by this client since the release of the 2012 version and it has been upgraded previously without issue, so I am unsure of what had changed in this version.

That was not the end of the story though. When I tested Management Reporter was working fine, it was. However, I’d logged in using the sa account. When users started logging in they were finding that they were unable to connect to the GP company database:

I’d seen this error message before and it is because the System DSN used by Dynamics GP was using the FQDN, but now the legacy connector in Management Reporter i using the server name so the password encryption will be different.

I didn’t want to remove the legacy connector and try to install it again as I was pretty sure we’d have the same problem as previously. Instead I decided to have a go at updating the connection used by Management reporter which is stored in the Reporting.ControlCompany table and which I noted I’d done in the previous bog post.

However, I didn’t post the SQL I’d used, so I needed to recreate it. The two highlighted sections are the server name which needed to be changed and to what:

/*
Created by Ian Grieve of azurecurve | Ramblings of an IT Professional (http://www.azurecurve.co.uk)
This code is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0 Int).
*/
UPDATE
	Reporting.ControlCompany
SET
	GLEntityConnectionInformation = REPLACE(CAST(GLEntityConnectionInformation AS VARCHAR(8000)), 'SQL01\GP', 'SQL01.example.com\GP')
GO

Obviously, take a backup of the database before running the script and test that it has worked correctly before allowing users back into Management Reporter.