In the previous post I covered the installation of SQL Server itself; in this post I’m going to cover the installation of SSRS. While it is possible to have SSRS installed and configured automatically when SQL Server is installed, but I have experienced problems with SSRS when doing this so I usually install it separately. You would also do a separate installation of SSRS if you had a reporting server where you were doing an install of SSRS.
To install SSRS launch the setup.exe on the installation media, click on Installation in the navigation pane and then click on New SQL Server stand-alone installation or add features to an existing installation:
The first item I’m going to cover is SQL Server itself; I have had problems before installing and configuring SSRS at the same time as SQL Server, so I now always separate these into three separate steps.
The first part is to install SQL Server; do so in SQL Server Installation Center by launching the setup.exe from the installation media:
I recently implemented Microsoft Dynamics GP for a client who is a UK subsidiary of an American company. This client is a heavy user of the Inventory Control module with over 30,000 items (you’ll see the relevance of this soon).
Shortly after the go-live, users started reporting that windows were opening very slowly; for example, it was taking almost 2 minutes to open the Sales Transaction Entry window. I sat with one of the users and looked at the problem with them; it took a few minutes, due to the slowness, of checking various windows before realising that it was the windows with an Item Number field on them which were slow opening.
I did a quick search online and found a post on Dynamics Code Blocks by Tim Wappat where he had encountered a similar issue which was being caused by the AutoComplete function; this would make sense as by default the AutoComplete will remember 10,000 entries per field.
Which with over 30,000 items and a couple hundred sales orders being processed everyday meant the AutoComplete was quickly building up for each user.
Tim’s solution seemed to be a little more convoluted than I woulr have expected and involved deleting files in the Windows profile. I did a test with one of the users, by deleting the AutoComplete entries via User Preferences () and clicking the AutoComplete button (ringed in red):
However, my most recent problem with Integration Manager did actually produce a useful error message:
Integration 'Invoices' is not ready to run due to the following problems:
- The destination could not be initialized due to the following problem:
Cannot create ActiveX component.
I did a search and found a most useful KB article from Microsoft which detailed the problem (Microsoft Dynamics GP hadn’t been written to the registry correctly) and also the solution.
I read the whole article and decided to try a shortcut of starting with step 3 of re-registering the Dynamics.exe. To do this open a Run or Command Prompt and type the following (this particular problem was encountered with Microsoft Dynamics GP 20103 R2):
"C:\Program Files (x86)\Microsoft Dynamics\GP2013\Dynamics.exe" /regsrver
When I retried the integration, it ran through without further problems.
I’ve been involved with a recent upgrade of Microsoft Dynamics GP 10 to 2015. Two of the new features we helped introduce is the use of Word Templates and the Email Documents to replace the old statement email functionality which was dependent on Adobe Writer.
To help the client make the transition from the old to the new, I created an SQL script to transfer the email addresses from the table, RM00106 (RM Statement Emails) used by the old Adobe Writer to the SY01200 (Address Email Master) used by the Email Documents functionality.
A recent project for a client was done using C# which requires the assembly to be registered using a different command. I am posting this here as a reminder to myself next time I need to do this.
When you register the assembly, you may receive a warning message about registering unsigned assemblies using the /codebase switch which is intended only with signed assemblies. If you trust the origin of the assembly then you can safely register the assembly and ignore the warning.
To register the .NET DLL, open a command prompt and type the following (the highlighted section is the name of the assembly being registered):
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\regasm.exe reportprinter.dll /codebase
To unregister a .NET DLL type the following:
%SystemRoot%\Microsoft.NET\Framework\v4.0.30319\regasm.exe reportprinter.dll /unregister
The highlighted section is the dll being registered or unregistered.