Logging is not configured by default so it has to be set up in BIDS. Even with logging configured, however, not all details will be logged to the log provider used. For instance, in my previous post where I discussed the AcquireConnection method call failed error, I talked about one cause being related to 32 bit providers in 64 bit environments. In the video embedded in that particular post, I showed the following error message from the BIDS Execution Results window:

[Connection manager "c:\ssis\ExcelFile.xlsx"] Error: SSIS Error Code DTS_E_OLEDB_NOPROVIDER_64BIT_ERROR.  The requested OLE DB provider Microsoft.ACE.OLEDB.12.0 is not registered -- perhaps no 64-bit provider is available.  Error code: 0x00000000.

However, for the person investigating a package failure by analyzing SSIS log files, for instance, the above error detail won’t be found. Instead, all they will see is the error:

SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER.  The AcquireConnection method call to the connection manager "c:\ssis\ExcelFile.xlsx" failed with error code 0xC0209303.  There may be error messages posted before this with more information on why the AcquireConnection method call failed.

Note, however, the highlighted error code, 0xC0209303.  If investigating purely from what has been provided in the log file, this error code will need to be manually interpreted by searching for it in the following article:

SSIS Error and Message Reference

Here is what the article provides in reference to the 0xC0209303 error code:

If the Diagnostic logging event has been selected when the logging was configured for the Package, the log should include clues before the AcquireConnection method call failed error to help in determining provider details.  In this case, the following Diagnostic events were logged:

 ExternalRequest_pre: The object is ready to make the following external request: 'IDataInitialize::GetDataSource(NULL, CLSCTX_INPROC_SERVER, ConnectionString: Data Source=c:\ssis\ExcelFile.xlsx;Provider=Microsoft.ACE.OLEDB.12.0;Persist Security Info=False;Extended Properties="Excel 12.0;HDR=YES";,...)'.

ExternalRequest_post: 'IDataInitialize::GetDataSource failed'. The external request has completed.

So, with a little effort, you can get more details from the log files than may actually be included in them.

DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER

The AcquireConnection method call to the connection manager "__" failed with error code __. There may be error messages posted before this with more information on why the AcquireConnection method call failed.

One of the most common reasons for this error is the lack of a 64 bit driver for the provider used by the connection manager mentioned in the error. The developer of SSIS packages/solutions should consider the environment to which their solution will ultimately be deployed long before the deployment stage. Whether or not the production environment is 64 bit or 32 bit is extremely important for several reasons – one being the availability of drivers in both environments.

There is common confusion around the drivers used by the Business Intelligence Development Studio (BIDS) environment verses the runtime environment.

BIDS

BIDS uses 32 bit drivers at design time when testing connectivity, previewing data, etc. When running/debugging a package in BIDS, the drivers used are determined by the Run64BitRuntime project property and whether or not the machine on which BIDS is running is 64 bit or 32 bit. If the development machine is 32 bit, 32 bit drivers will be used at design time and while running/debugging in BIDS. If the development machine is 64 bit, 32 bit drivers are used at design time and 64 bit drivers are used while running/debugging in BIDS by default, since the Run64BitRuntime property defaults to True. That is why it is possible to test a connection in BIDS and see it succeed, only to see the AcquireConnection method call failed error when running the package in BIDS. In that scenario, the 32 bit drivers are installed and working; but the 64 bit drivers are not.

Whether to change the default Run64BitRuntime setting depends on how you would like debugging to simulate the production environment. If ultimately the package will be deployed to a 64 bit environment and 64 bit drivers are available for the chosen providers, leave the default setting of True on 64 bit development machines and ensure that both 64 bit and 32 bit drivers are installed. Otherwise, change it to False. Keep in mind, however, that this setting, Run64BitRuntime, does not stay with the package once it is deployed. It is a BIDS project property which only impacts how the package is executed in BIDS.

Here is a quick demo of the Run64BitRuntime setting and its impact in a 64 bit development environment when using an Ole Db connection manager connecting to an Excel file:

SQL Server Agent

By default, the SQL Server Integration Services Package job step type in SQL Server Agent will run a package using 64 bit Dtexec.exe on a 64 bit server. Therefore, the same AcquireConnection method call failed error will occur when the job step runs if no 64 bit driver is correctly installed for the providers used by the connection managers in the package.

In SQL Server 2008 and later, a check-box is available to specify “Use 32 bit runtime” when the job step runs. This check-box is on the Execution Options tab in the New Job Step dialog:

Another option to use, especially in SQL Server 2005, is the Operating System (CmdExec) SQL Server Agent job step type, specifying the path to 32 bit Dtexec.exe in the command line:

C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\dtexec.exe /FILE "C:\SSIS\Package.dtsx" /CHECKPOINTING OFF /REPORTING E

The 64 bit/32 bit provider mismatch is one of the most common reasons for receiving the AcquireConnection method call failed error.  I will be explaining and, hopefully, clarifying other scenarios for that error in future posts.