Dynamics GP Integration Failing? Troubleshoot eConnect Destination Adapter Issues

Table of Contents

Microsoft Dynamics GP users often rely on powerful tools like Integration Manager and eConnect to streamline data entry and automation processes. Integration Manager provides a user-friendly interface to map data from various sources into Dynamics GP, while eConnect serves as the underlying technology, utilizing stored procedures and XML to facilitate data transfer securely and efficiently into the GP databases. When an integration using the eConnect destination adapter fails, it can halt critical business operations, requiring prompt diagnosis and resolution. This article delves into a common cause of such failures and provides a detailed resolution.

One specific error message frequently encountered when attempting to run an integration via the Microsoft Dynamics GP eConnect destination adapter in Integration Manager is a clear indicator of a permissions-related problem. This error directly points to an issue with the SQL Server side of the eConnect process. Understanding the structure of eConnect, which heavily relies on a set of dedicated SQL stored procedures to perform actions like creating or updating records, is key to diagnosing this type of failure.

Symptoms of the eConnect Stored Procedure Error¶

When you execute an integration within Integration Manager configured to use a Microsoft Dynamics GP eConnect destination adapter, the process may fail, presenting an error message similar to the following:

DOC X ERROR: eConnect error - The stored procedure procedure_name doesn’t exist.

This error message is highly specific. It indicates that the eConnect framework, specifically when trying to execute a required database operation, was unable to find or access a particular SQL stored procedure. The procedure_name placeholder in the error message will be replaced by the actual name of the stored procedure that eConnect attempted to call at the time of the failure. Examples of such stored procedures include ones used for creating sales orders, entering invoices, or updating customer records. While the message states the procedure “doesn’t exist,” this is often a misleading error; the procedure does exist in the database, but the user account attempting to execute it lacks the necessary permission.

Cause: Insufficient Database Permissions for the eConnect Service Account¶

The root cause of the “stored procedure doesn’t exist” error when using the eConnect destination adapter in Integration Manager typically stems from insufficient permissions assigned to the user account that the eConnect 10 for Microsoft Dynamics GP Microsoft COM+ component is configured to run under. The eConnect COM+ application acts as a bridge between Integration Manager (or any other application using eConnect) and the Dynamics GP SQL databases. It handles the communication and execution of the necessary stored procedures.

For the COM+ component to successfully interact with the Dynamics GP databases (both the DYNAMICS system database and the individual company databases), the user account associated with this service must have specific database roles assigned. If this user account lacks the required permissions, particularly the EXECUTE permission on the eConnect stored procedures, SQL Server will deny the request to run the procedure. The error message received by Integration Manager, while saying the procedure “doesn’t exist,” is SQL Server’s way of reporting that the user doesn’t have rights to interact with that object, effectively making it inaccessible to them. This security measure prevents unauthorized access or manipulation of the critical business data stored within Dynamics GP.

Resolution: Ensuring Proper Database Roles for the eConnect Service Account¶

To resolve the issue where the eConnect destination adapter fails due to a stored procedure error, the user account specified in the eConnect COM+ component must be granted the necessary permissions within Microsoft SQL Server. The standard and recommended approach for Dynamics GP is to make this user account a member of the DYNGRP database role. The DYNGRP role is a custom database role created during the Dynamics GP installation specifically to grant permissions to Dynamics GP users and service accounts. It provides the required SELECT, INSERT, UPDATE, DELETE, and critically, EXECUTE permissions on the vast majority of Dynamics GP objects, including the eConnect stored procedures.

The eConnect service account must be a member of the DYNGRP role on both the DYNAMICS system database and all company databases that the integration interacts with. Without membership in DYNGRP on a specific database, the eConnect component running under that user account will be unable to execute the stored procedures within that database, leading to the observed error for any integration targeting that company.

Step-by-Step Guide to Identify the eConnect Service Account¶

The first step in applying the resolution is to identify which Windows user account is configured to run the eConnect 10 for Microsoft Dynamics GP COM+ application. This account is the one that needs its database permissions adjusted.

1. Select the Start button, then select Run.
2. In the Open box, type dcomcnfg and press Enter or select OK. This opens the Component Services administrative tool.
3. In the Component Services window, navigate the tree view in the left pane: Expand Component Services, then expand Computers, expand My Computer, and finally expand COM+ Applications.
4. In the list of COM+ Applications, locate eConnect 10 for Microsoft Dynamics GP. Right-click on it.
5. From the context menu, select Properties.
6. In the properties window for eConnect 10 for Microsoft Dynamics GP, select the Identity tab.
7. On the Identity tab, you will see the user account configured to run this COM+ application. Note down the username and domain (if applicable). This is the account that needs to have the DYNGRP role assigned in SQL Server.

Once you have identified the user account, the next steps involve using SQL Server Management Studio (SSMS) to modify the permissions for this account within the Dynamics GP databases.

Step-by-Step Guide to Grant DYNGRP Role in SQL Server Management Studio¶

After identifying the eConnect service account, you need to ensure it is a member of the DYNGRP role in SQL Server. This process is performed using SQL Server Management Studio, connecting to the SQL Server instance hosting your Dynamics GP databases.

1. Open SQL Server Management Studio and connect to the SQL Server instance where your Dynamics GP databases reside.
2. In the Object Explorer pane, expand Security.
3. Expand Logins.
4. Locate the login that corresponds to the user account you identified from the eConnect COM+ application identity tab. If the login does not exist, you may need to create it first, mapping it to the Windows user account.
5. Right-click the login and select Properties.
6. In the Login Properties window, select the User Mapping page.
7. On the User Mapping page, in the “Users mapped to this login” list, find the rows corresponding to your Dynamics GP databases (the DYNAMICS database and all relevant company databases, e.g., TWO, FOUR).
8. For each relevant database (DYNAMICS and company databases), check the Map box next to the database name.
9. Once a database is mapped, the database user name will appear in the “User” column (often defaulting to the login name).
10. In the “Database role membership for: [Database Name]” list at the bottom of the window, check the box next to DYNGRP.
11. Repeat steps 8-10 for every Dynamics GP database (DYNAMICS and all company databases) that your eConnect integrations will interact with.
12. Select OK to save the changes to the login properties.

After making these changes in SQL Server Management Studio, the eConnect service account now has the necessary permissions (via membership in the DYNGRP role) to execute the eConnect stored procedures within the specified Dynamics GP databases.

Verifying the Resolution¶

After granting the DYNGRP role, attempt to run the failing integration in Integration Manager again. If the permissions were the sole cause of the “stored procedure doesn’t exist” error, the integration should now proceed without this specific error.

It’s also good practice to restart the eConnect 10 for Microsoft Dynamics GP COM+ application after making permission changes in SQL Server, although it is not always strictly necessary. To do this:

1. Return to the Component Services window (dcomcnfg).
2. Navigate to Component Services > Computers > My Computer > COM+ Applications.
3. Right-click on eConnect 10 for Microsoft Dynamics GP.
4. Select Shut down.
5. Right-click again on eConnect 10 for Microsoft Dynamics GP.
6. Select Start.

Additional Troubleshooting Context for eConnect Integrations¶

While insufficient permissions are a common cause for the specific “stored procedure doesn’t exist” error, other issues can also prevent eConnect integrations from running successfully. Understanding the broader context can help in troubleshooting.

• SQL Server Connectivity: Ensure the server hosting Integration Manager and the eConnect COM+ component can properly connect to the SQL Server instance hosting the GP databases. Network issues or firewall rules can block communication.
• Database Status: Verify that the Dynamics GP databases are online and accessible in SQL Server.
• eConnect Installation: Confirm that eConnect was installed correctly on the server where the COM+ component is running.
• Integration Manager Configuration: Double-check the connection settings within Integration Manager, ensuring the correct server name, database names, and authentication methods are specified.
• Data Issues: Even with correct permissions, integrations can fail if the source data is invalid, missing required fields, or violates Dynamics GP’s business logic (e.g., trying to use a non-existent customer ID, incorrect GL account format). These often result in different eConnect errors, but it’s worth considering if the permission fix doesn’t fully resolve the problem or if new errors appear.

Troubleshooting Checklist¶

Here is a quick checklist to follow when troubleshooting eConnect integration failures related to destination adapter issues:

Check Item	Status (Yes/No/NA)	Notes
Identify the eConnect COM+ Service Account		Use dcomcnfg > eConnect Properties > Identity tab
Verify Login Exists in SQL Server for Account		SSMS > Security > Logins
Map Login to Dynamics GP Databases (DYNAMICS, Co.)		SSMS > Login Properties > User Mapping
Grant DYNGRP Role to User in Mapped Databases		SSMS > Login Properties > User Mapping (Check DYNGRP)
Restart eConnect COM+ Application		dcomcnfg > Shut down > Start
Test Integration in Integration Manager		Run the integration that was previously failing
Check SQL Server Connectivity		Ping SQL Server, check firewall rules
Verify Database Status in SSMS		Databases are Online
Review Integration Manager Connection Settings		Correct server, databases, authentication
Examine Integration Log for New/Other Errors		If the original error is gone, new errors might point to data issues

Implementing proper permission management for service accounts, including the one running the eConnect COM+ component, is a fundamental security and operational best practice in any Dynamics GP environment. Assigning the DYNGRP role ensures the necessary access for eConnect operations while adhering to standard Dynamics GP security models.

Encountering integration errors can be frustrating, but systematically addressing potential causes, starting with the most common ones like permission issues, is key to a quick resolution. The “stored procedure doesn’t exist” error is a strong indicator that the eConnect service account needs its SQL Server database roles reviewed and corrected by adding it to the DYNGRP.

Have you encountered this specific eConnect error before? What troubleshooting steps did you find most effective? Share your experiences and tips in the comments below!