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 (AutoComplete button (ringed in red):
) and clicking the
I’ve probably said this before, but Integration Manager can be both very useful and also most infuriating, because when you get an error the error message usually isn’t useful.
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.
In the past when I have needed to manually register DLLs they have been C++ or VB ones which are registered using the regsrver command.
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.
I make a lot of use of virtual machines for both testing and demonstrating Microsoft Dynamics GP. As a company, when I joined, Perfect Image tended to use VMware (I’ll reserve comment, which I realise tells it’s own story), but more recently have started making more use of Microsoft Hyper-V, which is what I also use at home for testing and writing my blog and books.
After installing Hyper-V on my work laptop I created a virtual machine and clicked start. Unfortunately, I received the below error messages:
I did some digging around and found that although Hyper-V was installed, the hypervisor wasn’t running. Fortunately, the laptop I have does support Hyper-V and I only had to do one thing which was to enable the hypervisor by opening an elevated command prompt and type the following command:
bcdedit /set hypervisorlaunchtype auto
Once I had run the command I was able to start the virtual machine without further problem; at least with Hyper-V.
What I found was that with the hypervisor running, I wasn’t able to start a VMware virtual machine. So a second command can be used to disable the hypervisor for those times when I need to use a VMware virtual machine:
bcdedit /set hypervisorlaunchtype off
Hopefully, I’ll be able to complete the transition away from VMWare very soon and stop toggling from one to the other.
Taking a slight diversion from my usual subject matter with this post. I was trying to connect to a clients system via VPN a short while ago when I received error 778:
Error 778: It was not possible to verify the identity of the server
I did a little digging and found that this error actually relates to the username and password being incorrect. I checked our records and found that the password had been reset since the last time I logged on; after entering the new details I was able to log in successfully.
It would be nice if the error message had been a little more descriptive of the actual problem, but at least it was a simple solution.
A recent install of eConnect ran into a small issue; after the installation was complete, the eConnect service wouldn’t start. In the Windows Event Log there were two errors shown:
This probably seems like an obvious one, but when you’re going to install the web client for Microsoft Dynamics GP make sure that any previous installs have had a reboot done.
I had this come up recently when trying to do an install. Earlier that day I had installed a new feature on the server (in this case the Windows Authentication feature of the Internet Information Services IIS role), but not done a reboot as one wasn’t asked for.
However, the web client installation ended prematurely and it was only when I checked the Windows Event Viewer that I found the error relating to the pending reboot.
This was particularly annoying as the premature end was only after I clicked on the Install button after entering all of the required information at the preceding steps.
Based on this error, and when it appeared, from now on I am going to reboot the server I’m installing the web client before starting.
We had a peculiarity the other day when updating a Word template for a client. We added some new fields via Report Writer and then created a new Word Template; when then modifying the Word template the fields usually show in the XML schema, but this time we found they weren’t.
After a couple of fruitless minutes checking the modified report and creating a new version of the Word template without success I started wondering about already open applications. In particular MS Word itself was already running with an unrelated document open.
I closed down all open Word documents and, in Template Maintenance ( ), clicked the Modify button; when the Word template opened the new fields were showing in the XML schema.
This is something I have experienced before without being able to pin down why which caused..shall we say…a certain level of frustration. I’m not sure why having Word open caused the XML schema not to be refreshed when creating a new document, I am pleased that at least I can void the problem by making sure all open instances of Word are closed before starting.
A client recently logged a problem with our Service Desk to report that an Integration Manager integration wasn’t working; when trying to run the integration they received an error message on every line of the integration:
Opening source query...
Establishing source record count...
DOC 1 ERROR: Syntax error (missing operator) in query expression 'UCase(DATE#######) = UCase('' AND [RUN NUMBER] = ')''.
DOC 2 ERROR: Syntax error (missing operator) in query expression 'UCase(DATE#######) = UCase('' AND [RUN NUMBER] = ')''.
DOC 10 ERROR: Syntax error (missing operator) in query expression 'UCase(DATE#######) = UCase('21 January 2015') AND UCase([RUN NUMBER]) = UCase('HP33')'.
DOC 11 ERROR: Syntax error (missing operator) in query expression 'UCase(DATE#######) = UCase('21 January 2015') AND UCase([RUN NUMBER]) = UCase('HP33')'.
ERROR: Max Errors Exceeded at 11, Integration Canceled
ERROR: Integration canceled during document integration.
100 documents were read from the source query.
11 documents were attempted:
0 integrated without warnings.
0 integrated with warnings.
11 failed to integrate.
After doing some debugging of the integration, we identified the problem as being caused by the source column headers; all of which had multiple # at the end.
For example, as you can see in the above error message, DATE was displaying as DATE#######.
We went through the source removing all of the # symbols and were then able to run the integration without receiving more errors.