Friday, June 14, 2013

Submitting a Microsoft Dynamics Support Case: What to Send

Doug Pitcher, curator of the OFFICIAL 100 most famous, awesome and totally influential Dynamics people for 2013, has an excellent article on Interacting with Microsoft Dynamics Support.

In his post, Doug offers some excellent information regarding how to handle support cases, and some great tips on how to save time and frustration when you are going through the support process.  And when Doug speaks, you should listen.

Related to Doug's topic of working with Dynamics Support, one thing that I like to do is "front load" the support case as much as possible.  By that, I mean that when I submit a support case, I want to have clear documentation of the issue, as well as full documentation of everything I have done to try and troubleshoot the issue, including screen shots, sample data, error messages, data files, etc.

When I submit the support case, I include a high level version of this info, describing the issue and what we have already tried.  But, I also document everything in great detail in a Word document and always attach the Word document to the case.

So far with this technique, I have always gone straight to the escalation engineers with the problems that I have encountered.  This would seem to indicate that it is saving me time avoiding the basic questions that a first level support tech might ask--but it might also be due to the fact that most of my support issues are eConnect related.

Here is an example of an old support case, and below is the Word document that I attached.

We developed a GP 9 AddIn DLL that uses eConnect to import a payroll batch.  The GP 9 AddIn has been working fine for many months.

The AddIn was recently upgraded to GP 2010.  No modifications were made to the AddIn other than to upgrade to GP 2010 and eConnect 2010.

The AddIn works fine on the development server and TWO database.

When installed the AddIn in the client's test environment, the AddIn receives the following error when trying to import a payroll batch:

The stored procedure 'taCreatePayrollBatchHeaderInsert' doesn't exist.

We are able to reproduce the issue on two different client servers, so it does not appear to be computer-specific.

To troubleshoot the issue, we added debugging code to the AddIn to display the SQL connection string that is being passed to eConnect.

The server name and database name in the connection string appears to be correct.

We also used the Direct Document Sender to submit the payroll transaction XML directly to eConnect, and we receive the same error message:

Integrated Security=SSPI;Persist Security Info=

False;User ID=sa;Initial Catalog=ORION;Data Source=GreatPlains;Packet Size=4096

Microsoft.Dynamics.GP.eConnect.eConnectException: The stored procedure 'taCreatePayrollBatchHeaderInsert' doesn't exist.

We have verified the following on the SQL Server:

1. The stored procedure does exist in the client's GP 2010 database
2. The eConnect domain user is a SQL user assigned to the database and assigned to the DYNGRP role
3. The DYNGRP role does include EXEC access to the stored procedure

The client environment and development environment both have eConnect version 11.0.1812.0 installed (June 2011 hotfix).

Please see the attached Word document with screen shots, along with the sample XML file that we are submitting to eConnect.

Please let us know if you require any additional information.


Here is a link to the Word document that I submitted with the case.



Update:  For any die-hard eConnect geeks who were left hanging by the support case I posted above, here is the very obscure solution.

The problem was that when the client setup the SQL Server login for eConnect, they set the Default Schema value to equal the user name.  The Default Schema should have been left as dbo for all databases.


Changing the default schema back to dbo did not resolve the problem.  I had to delete the eConnect schema from all databases, and then delete the eConnect SQL login.  I then re-created the eConnect login and users.



Written By Steve Endow

Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

You can also find him on Google+ and Twitter



3 comments:

Doug Pitcher said...

I would have sent you to an escalation engineer as well. ha. I agree with front loading the case info. It helps to get to the resolution more efficiently. I often just ask for a phone call because to write up the issue takes a while as well. Great follow up blog.

Unknown said...

Steve,

You are such a tease - you didn't even tell your loyal followers the solution to your issue.

The case sounds familiar, I think I took this one. Wasn't the issue the schema on the proc?

Steve Endow said...

Hi Patrick,

Yes, you did handle this case with me.

And you have amazing memory and are correct. The issue had to do with the Default Schema setting for the eConnect SQL login.

The default schema on the TWO database was dbo for the eConnect login, but for the client databases, the schema was set to the domain user (DOMAIN\eConnect).

I somehow stumbled across that and apparently a light bulb came on.

Steve