This blog has relocated to https://blog.steveendow.com/. All future content will be published there.

Update: For a solution, refer to the comments section at the end of this post: Consider temporarily adding the eConnect service account to the Local Administrator group.

Update 2: Adding the eConnect domain user to the Local Administrator group didn’t resolve the issue for a recent client. The system administrator rebooted the server as a last resort. The eConnect error was recorded in the event log after the reboot. Therefore, in some cases, a server reboot may be necessary.

Update 3: In a new GP 2018 VM, I ran into this eConnect permission problem. Even after adding the eConnect Windows user to the local Administrators group, I continued to receive the log error. I then restarted the eConnect service, which appears to have reloaded eConnect with Administrator privileges and fixed the issue. So, while a server reboot might not be necessary, restarting the eConnect service might be necessary to update the permissions.

After upgrading an eConnect integration to Dynamics GP 2015, I got this odd error:

Exception type:Microsoft.Dynamics.GP.eConnect.eConnectException
Exception message:The source was not found, but some or all event logs could not be searched.  To create the source, you need permission to read all event logs to make sure that the new source name is unique.  Inaccessible logs: Security.
Stack Trace:   at Microsoft.Dynamics.GP.eConnect.ServiceProxy.CreateTransactionEntity(String connectionString, String xml)   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.EntityImportImplementation(String connectionString, String sXML, Boolean isTransaction)   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.ProcessEntityImport(String connectionString, String sXML, Boolean isTransaction)   at Microsoft.Dynamics.GP.eConnect.eConnectMethods.CreateTransactionEntity(String connectionString, String sXML)

The phrase “Inaccessible logs: Security” stood out. This made me think of problems I’d had when an application couldn’t write to a Windows Event Log because it didn’t exist, couldn’t be created, or the program didn’t have write permissions.

I searched through all of the logs in the Windows Event Viewer but was unable to determine the source of the problem.

I finally got an error I recognized after running the GP 2015 integration a few more times.

Error Number = 936  Stored Procedure= taPMDistribution  Error Description = Vendor number does not existNode Identifier Parameters: taPMDistribution

The integration ran successfully and the strange “The source was not found” message vanished once I corrected the vendor ID in my test data file.

Then I deployed the integration to the customer’s workstation, and the “The source was not found” error message resurfaced. After a few more tests, we got a standard eConnect error message, corrected the data, and the integration worked perfectly.

My theory is that there is a problem with the eConnect 2015 installation or with the procedure that generates or writes to the eConnect event log when the initial error occurs. The error occurs only once, after which the log is corrected, and subsequent errors are logged appropriately.

Because the problem appears to be a one-time occurrence that disappears on its own, you should be able to safely ignore it. Although it is perplexing for users, it should not be a problem if you warn them ahead of time or can recognize and explain the problem to them.

Here’s some GP trivia: Did you know that the error message says “eConnect12” despite the fact that GP 2015 is internally version 14?

Steve Endow is based in Los Angeles and is a Microsoft MVP for Dynamics GP and a Dynamics GP Certified IT Professional. He is the proprietor of Precipio Services, which offers Dynamics GP integration, customization, and automation solutions.

He can also be found on Google+ and Twitter.

http://www.precipioservices.com