Partial Explanation of eConnect 2010 "Distributed Transaction" Warnings

In my last post, I discussed an issue where my Windows Event Log filled up with thousands of eConnect 2010 warning messages saying "Distributed transaction was used."

Many thanks to guru Louis for responding to the post and giving me some great info explaining what the eConnect 2010 "Distributed Transaction was used" warning meant and why it might be occurring.

First, just a reminder that eConnect 2010 is working great, and my data was importing into GP 2010 just fine--I'm only receiving warnings, not errors, so they are not interfering with my integration.  I just happened to notice the hundreds of warnings because my Event Log filled up.

Louis explained that for performance reasons, distributed transactions are not used or enabled by default with eConnect 2010, so what I am seeing is eConnect 2010 issuing a warning to let me know that my import is incurring the extra overhead of a distributed transaction.  He then offered some pointers to track down why my import was invoking distributed transactions.

In the case of my customer import, I wasn't intentionally doing anything related to a distributed transaction, and honestly, before today I didn't know enough about them to know why or when they might be used.  I checked my connection string to confirm that it wasn't changing during my import, and I confirmed that I hadn't enabled any settings to turn them on.

I then went ahead and upgraded the eConnect 9 SOP invoice and cash receipt imports that would accompany the customer import.  I was afraid they would have the same problem, but to my surprise, neither wrote a single entry to the eConnect event log.  They worked perfectly.  Hmmm.

So it was only my customer import that issued the warnings, which seemed really strange.  The customer record is quite simple, so I couldn't imagine what would require a transaction.

And then I remembered something.  As part of my customer import, I am importing e-mail addresses.  And as all good students of GP and eConnect know, there is no handy e-mail address field on the customer window.  It's tucked back in the Internet Information window in GP, and in the taCreateInternetAddresses and CMPInternetAddressType in eConnect.  So...what if sending these with the customer record were somehow causing eConnect to  invoke a distributed transaction?

So I commented out the code that adds the internet address type to my customer XML, and re-ran my integration.  Viola!  No entries in my eConnect event log!  Hmmm, so for some reason the presence of the customer internet addresses is triggering a distributed transaction on one of my servers. 

This is a great find, but as the title says, it's only a partial explanation.  This problem only occurs on my 32-bit server, and doesn't occur on my 64-bit server or the client's 64-bit server.  So my guess at this point is that it might be a configuration issue with my 32-bit machine, or a quirk in the 32-bit version of eConnect 2010.

Fortunately it isn't a show stopper, just a head scratcher, so it won't interfere with my client's GP 2010 upgrade schedule. And in the process, I learned alot more about eConnect 2010 alot faster than I would have if everything worked perfectly.

From that learning, I have a few more ideas for eConnect 2010 posts on deck...