We recently hit a problem on a project we were working on whereby we were forced to switch from using a native BizTalk database adapter to using the third-party Community Adapter for ODBC which has been refactored for BizTalk 2010 by TwoConnect.  Having access to the source code allowed us the opportunity to work around a very specific issue while we hold out the hope that Microsoft applies a permanent fix to the problem for us (I’ll blog about this issue soon).

This has been my first time dealing with the ODBC adapter for BizTalk and I must say that while it is far from perfect and does have limitations (just search for “TODO” in the source code and you’ll see that there is much room for improvement), it has far exceeded my initial expectations and contains a rather elegant project structure which enabled me to make my required changes in a structured and sensible manner, and also contains some pretty competitive schema generation and testing tools.

One major issue I had however was that when I deployed the adapter using the MSI that was built using the install project that is included with the source code, I started seeing the below error every time I tried to start my receive locations.

The Messaging Engine failed to create the receive adapter “ODBC”.
InboundAssemblyPath: “NULL”
InboundTypeName: “Microsoft.BizTalk.Adapters.ODBC.RunTime.ODBCReceiveAdapter.ODBCReceiver, ODBCAdapterManagement, Version=1.2.0.0, Culture=neutral, PublicKeyToken=0ad1f077efbaab97, processorArchitecture=MSIL”
Exception Details: “Could not load type ‘Microsoft.BizTalk.Adapters.ODBC.RunTime.ODBCReceiveAdapter.ODBCReceiver’ from assembly ‘ODBCAdapterManagement, Version=1.2.0.0, Culture=neutral, PublicKeyToken=0ad1f077efbaab97, processorArchitecture=MSIL’.”

Luckily I managed to find a comment on a blog post (thank god for the blogosphere) which pointed me in the right direction.  A user called “dawa” pointed out that the wrong InboundTypeName and OutboundTypeName were registered in the dbo.adm_Adapter table in the BizTalkManagementDb database.  The InboundTypeName really should be “Microsoft.BizTalk.Adapters.ODBC.RunTime.ODBCReceiveAdapter.ODBCReceiver, ODBCReceiveAdapter, Version=1.2.0.0, Culture=neutral, PublicKeyToken=0ad1f077efbaab97, processorArchitecture=MSIL” but is instead “Microsoft.BizTalk.Adapters.ODBC.RunTime.ODBCReceiveAdapter.ODBCReceiver, ODBCAdapterManagement, Version=1.2.0.0, Culture=neutral, PublicKeyToken=0ad1f077efbaab97, processorArchitecture=MSIL”.  Likewise the OutboundTypeName should be “Microsoft.BizTalk.Adapters.ODBC.RunTime.ODBCTransmitAdapter.ODBCTransmitter, ODBCTransmitAdapter, Version=1.2.0.0, Culture=neutral, PublicKeyToken=0ad1f077efbaab97, processorArchitecture=MSIL” but is instead “Microsoft.BizTalk.Adapters.ODBC.RunTime.ODBCTransmitAdapter.ODBCTransmitter, ODBCAdapterManagement, Version=1.2.0.0, Culture=neutral, PublicKeyToken=0ad1f077efbaab97, processorArchitecture=MSIL”.

Now I’m as brave as the next person, but making changes to the BizTalk management databases on non-development environments should really be a no-no.  If you actually open the Install.vdproj file using a text editor you’ll find that you can adjust the InboundTypeName and OutboundTypeName.  Once this is done you can rebuild the MSI and it will now behave correctly.  If however you have already previously installed the ODBC Adapter and have encountered this error, you will need to uninstall the ODBC Adapter from the Add/Remove Programs control panel and you will also need to deregister the ODBC Adapter in the BizTalk Administration Console by browsing to Adapters within Platform Settings and deleting the ODBC Adapter (you will need to ensure that all receive locations and send ports that use the ODBC adapter have been deleted first).  You can then install the fixed MSI and register the ODBC adapter again, and it will now contain the correct InboundTypeName and OutboundTypeName.

I don’t believe that this problem exists with the MSI file that is published on TwoConnects website as I didn’t face this problem until I installed an MSI built from the source code (I had originally just installed the MSI from their website).  It only appears to be in the source code that they have published.  I will advise them of this problem but thought I better document it before it catches the next unwary developer off guard.