I was trying out the Query Database object to see how I could get some information from Configuration Manager's database, and I decided to use the ODBC connection type, since it seemed like something that would be more usable from an enterprise perspective than putting credentials in the object itself. I went through the typical System DSN creation process using the ODBC Administrator, then added the name of the new DSN to my Query Database object.
Next I opened the workflow in the testing console and ran it. The object failed and the error I got was "The specified DSN contains an architecture mismatch between the Driver and the Application":
After a quick Bing search, I found this page on MSDN: http://msdn.microsoft.com/en-us/library/ms712362(v=VS.85).aspx which says that it's a64-bit versus 32-bit issue. I know that the code was written on a 32-bit platform, so this is likely the culprit. So, following the instructions, I remove the DSN I just created, and then I launch c:\windows\sysWOW64\odbcad32.exe to get the 32-bit version of the ODBC Administrator. I create a new DSN and save it, and now my problem is gone! I just thought I would share this with you, since it's likely to happen to a lot of people once everyone starts installing on Server 2008 R2.
I've done accordingly but still unable to run the policies.I'm able to test them using testing console but not able to run them.I can't see any event log.Only warning messages can be seen---"Action server has stopped running" and "Deployed policy is not running". I've only one server for Action service,Management service and Integration service as well as SQL 2008.Is this Configuration okay???Which DSN I've to change?I've changed user DSN
If it works in the testing console but not as a normal policy, then it's likely because of user rights. The testing console runs under the user context of the logged in user, where the Action Server runs under the context of the assigned service account.
Wow, Thanks Robert I was just banging my head against this one