eConnect error - The stored procedure doesn't exist

Patrick Roth - Click for blog homepageI ran across an odd eConnect issue a while back that I thought I'd share today.

In this case, the customer had recently updated to GP 2010 and updated their application to eConnect 2010 from the previous version that worked fine.

But now under GP 2010, when trying to run their eConnect integration it would fail with the error:

Microsoft.Dynamics.GP.eConnect.eConnectException: The stored procedure 'taCreatePayrollBatchHeaderInsert' doesn't exist.
  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.CreateTransactionEntity(String connectionString, String sXML)
at DirectDocSenderDotNet.FrmDocSender.btnSend_Click(Object sender, EventArgs e)

Now this was interesting in that it wasn't a standard business logic error and was a straight SQL exception instead.

Checking SQL, we verified that indeed the proc DID exist and the DYNGRP did have permissions to it (even though this didn't appear to be a permissions issue).  The "eConnect" user was assigned to the DYNGRP role.

For kicks, we used DBMaintenance.exe to recreate the Dynamics database procs again - still the same issue despite the fact that the proc was there.

We executed a SQL trace on the server during this process but that seemed normal - except for the error.

We then checked the User settings and the ISV noticed something unusual.

For some reason, the Default Schema for this user for the database was set to "eConnect" instead of "dbo".

Now this made more sense - since the Default Schema for the database was not dbo, it couldn't see any objects that were dbo.  We didn't notice any other issues with this user because it was the eConnect user and not a GP user so there were no Dynamics errors to worry about.

From there, it was a simple matter of setting the user default schema to 'dbo' and the application worked correctly from there.

Best regards,
Patrick Roth
Dynamics GP Developer Support