SSIS - An OLEDB Error Has Occurred
Title:: DTS_E_OLEDBERROR
This is a very generic error and can occur due to multiple reasons. I am documenting as much as of them based on Case studies. Refer to the description and the error codes for each of the unique errors.
A:
+++
Error:
"DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040E4D. An OLE DB
record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80040E4D
Description: "Login failed for user '<User_Name>'."
Symbolic Name: DTS_E_OLEDBERROR
The hexadecimal value for this error number = 0x80040E4D.
Cause:
When you create a package on your local machine and create a connection in it, you have the option to save the password of that connection. However by default it encrypts this password so that in can only be decrypted when you' re running the package on the same machine, with the same account. This holds good only if the Connection Manager uses SQL Authentication or connects to a Database which does not support Windows Integrated Authentication (e.g. Oracle).
So, in the above scenario, if the package is deployed to a Remote Sql Server, it fails with the "Login failed.." error as it is not able to decrypt the password. (Note: It runs fine if deployed in the local Sql Server)
Resolution:
To correct the problem, you should opt between either of the two options:
1. Encrypt the package with "EncryptSensitiveWithPassword" or "EncryptAllWithPassword" and provide a package password each time User wants to edit/manipulate the package.
2. Create a configuration file to provide the connection information during Package runtime.
References:
How to: Add a Package Configuration: https://technet.microsoft.com/en-us/library/ms140213.aspx
Setting the Protection Level of Packages: https://msdn.microsoft.com/en-us/library/ms141747.aspx
B:
+++
Error:
0xC0202009 at Package, Connection manager "<NAME>": SSIS Error
Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040154.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components"
Hresult: 0x80040154 Description: "Class not registered".
Symbolic Name: DTS_E_OLEDBERROR
The hexadecimal value for this error number = 0x80040154.
Cause:
This is a very common error when a package is deployed in a 64-BIT environment and the package is using Microsoft Providers that is not available in 64-BIT (e.g. Microsoft JET provider and Microsoft provider for Oracle).
The Integration Services design environment is a 32-bit environment and you see only 32-bit providers while you are designing a package. Therefore, you can only configure a connection manager to use a specific 64-bit provider if the 32-bit version of the same provider is also installed. At run time, the correct version is used, and it does not matter that you specified the 32-bit version of the provider at design time. The 64-bit version of the provider can be run even if the package is run in Business Intelligence Development Studio. Both versions of the provider have the same ID. To specify whether the Integration Services runtime uses an available 64-bit version of the provider, you set the Run64BitRuntime property of the Integration Services project. If the Run64BitRuntime property is set to true, the runtime finds and uses the 64-bit provider; if Run64BitRuntime is false, the runtime finds and uses the 32-bit provider.
When the package is deployed as a job in a 64-BIT Sql Server, it would fail with the above error as it will use the 64-BIT DTExec.exe (C:\Program Files\Microsoft Sql Server\DTS\Binn\DTExec.exe) to run the job and it will not be able to recognize the 32-BIT providers.
Resolution:
1. When the package fails as a job, we can provide two resolutions:
A) Modify the job step of the failing package, change the "Type" to Opearting System (cmdExec) and edit the command line manually to run it through the 32-BIT DTExec.exe. You need to prefix the full path of 32-BIT DTExec.exe before the command (Typically, under default installation, the path would be (C:\Program Files (x86)\Microsoft Sql Server\DTS\Binn\DTExec.exe).
B) Change the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTS\Setup\DTSPath” to point to the 32-BIT DTExec.exe. This way it would invoke all the jobs through this 32-BIT DTExec.exe.
Note: The method A) applies to a specific job while method B) would apply to all the jobs deployed in Sql Server. In SQL Server 2008, there is an option in the job step properties page to use 32-bit instead of 64-bit. Under 2005, though, the only way to control it is to use a CmdExec step to call the 32-bit version of DTEXEC.
2. There would be scenarios where this error is encountered when a package is executed through a .NET program using the SSIS APIs(using LoadFromSqlServer(), Execute()). In that scenario, we need to change the Target Platform to "x86" from the Project Properties.
3. There might be scenarios where the providers used in the connection managers would be missing from the System where the package is run. In that case, the execution of the package would fail BOTH from BIDS as well as from Sql and the resolution would be install the appropriate provider.
References:
Integration Services Considerations on 64-bit Computers: https://msdn.microsoft.com/en-us/library/ms141766(SQL.90).aspx
MSDN Social Link that has a good discussion regarding this error: https://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/b1d5de28-b80b-4f34-a135-c68e87039c58/
C:
+++
Error:
An OLE DB error has occurred. Error code: 0x80004005. An OLE DB record is available.The AcquireConnection method call to the connection manager "<Name>" failed with error code 0xC0202009.
Symbolic Name: DTS_E_OLEDBERROR
The hexadecimal value for this error number = 0x80004005.
Cause:
The owner of the job determines the security context in which the job is run. If the job is owned by a SQL Server login account that is not a member of the Sysadmin fixed server role, the SSIS package runs under the context of the SQL Server Agent proxy account.
If you want the SQL Server Agent proxy to run jobs that connect to an instance of SQL Server, the SQL Server Agent proxy account must have correct permissions to the instance of SQL Server.
If you want the SQL Server Agent proxy account to run a job that runs as an SSIS package, the SQL Server Agent proxy account must have the Read permission and the Write permission to the Temp directory of the SQL Server Agent Service startup account.
Resolution:
To resolve this issue, you must change the permissions for the Temp directory of the SQL Server Agent Service startup account. Grant the Read permission and the Write permission to the SQL Server 2005 Agent proxy account for this directory.
References:
Error message when an SSIS package runs that is scheduled to run as a SQL Server Agent job: "An OLE DB error has occurred. Error code: 0x80004005": https://support.microsoft.com/kb/933835