All About SSIS

The SQL CE and IIS 7.5 story:

Debarchans — Tue, 06 Jul 2010 13:52:47 GMT

Last week I thought I should migrate my SQL CE 3.5 sample applications connecting and opening a Sql Compact Edition Database from Windows Server 2003 to Windows 7. In fact, I tried migrating them both to Win 7 and Win 2008 R2 and straight away ran into issues. I worked on it further on figured out that he same code runs just fine when I connect through a Windows/Console application, its only when going through IIS, its throwing the below error:

“SqlCEException: The operating system does not support the Encryption Mode provided”

Honestly, it did not make much sense to start with as the same Web application works like a charm on my Windows Vista and Windows 2003 machines. Surely, it had to do something with IIS as the web server is the only component that has the change across my version of Windows.

Note: In Windows 2003/Vista/Windows 2003 R1, the version of IIS that comes bundled is IIS 7; however, in Windows 7/Windows 2008 R2, the IIS version is 7.5.

Of course, I have tried connection string variations inside my code to attempt to use the proper encryption mode, and all three options (engine default, platform default, ppc32003 compatibility) yielded the same results, that SqlCeException being thrown which in fact I was expecting because logically there should not be anything that I need to change in the code as the same piece works perfectly in IIS 7.

Resolution:

I continued my research and figured out that in IIS 7.5 the Default Application Pool (My Sql CE app is running under the Default App Pool) runs under an identity called Application Pool Identity.

This is a virtual user account that is introduced to simplify user management and it seems to lack the required privileges to connect to Sql CE Database. Please read more about this below:

https://learn.iis.net/page.aspx/624/application-pool-identities/

To confirm on my understanding, I compared the working IIS and found that in all the working scenarios, my application pool was running under NetworkService account. I changed the App pool identity in my IIS 7.5 Server, recycled it and when I re-ran my application voila!! It works !!

I am yet to figure out what exactly are the differences in terms of permission/authentication when we use the new Virtual User identity in IIS 7.5 and yet to do the root cause analysis of the error (may be granting some permissions/roles to the Virtual User would also resolve this error and run it successfully under Application Pool Identity as well), but I hope that this post is going to help our users to at least resolve the error and get everything up and running in a timely manner. Once I do the RCA and figure out the actual reason for the error, I would update my post.

How to enable SQL*Net Client Side Tracing

Debarchans — Tue, 06 Jul 2010 13:49:56 GMT

How many times we have run into issues with client applications/SSIS Packages connecting to Oracle Databases and erroring out intermittently? Well, I have run into such scenarios on numerous occasions and the intermittent nature of the error makes it really difficult to figure out the root cause of such issues. In such cases I have found out Sql*Net client side tracing extremely useful in narrowing down the issue which often boils down to a simple Network Connectivity issue or a connectivity issue due to a configuration or protocol error on the Oracle side.
In plenty of cases we need to collaborate with Oracle support as the error might be coming from the Oracle Data Access Layer as well as the Connection/Command Timeout settings in the Oracle Configuration files. The purpose of this write up is NOT to discuss the possible issues and their troubleshooting methods but I would focus mainly on enabling the tracing (Detailed Tracing is turned OFF by default), discuss a few of the tracing switches available and their significances so that we are able to dig deep into the actual error message and consider possible resolution options.

The aim of this document is to overview SQL*Net, Net8, Oracle Net Services tracing and logging facilities. Although only basic information on how to enable and disable tracing and logging features is described, the document also serves as a quick reference. The document provides the reader with the minimum information necessary to generate trace and log files with a view to forwarding them to Oracle Support Services (OSS) for further diagnosis. The article does not intend to describe trace/log file contents or explain how to interpret them. For detailed information about all the switches and their implementations, please refer to: https://download.oracle.com/docs/cd/A57673_01/DOC/net/doc/NWTR23/ch3trc.htm

As I mentioned earlier, detailed Level of Sqlnet tracing is turned OFF by default. As a result, when a connection error occurs, we see entries similar to the following in the sqlnet.log file:

Fatal NI connect error 12560, connecting to: (DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oracleORCL)(ARGS='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=ORCL)(CID=(PROGRAM=c:\windows\system32\inetsrv\w3wp.exe)(HOST=SFTNETAPP1)(USER=svcsys_qrmdms))))

VERSION INFORMATION:
TNS for 32-bit Windows: Version 11.1.0.7.0 – Production
Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version 11.1.0.7.0 – Production
Windows NT TCP/IP NT Protocol Adapter for 32-bit Windows: Version 11.1.0.7.0 – Production
Time: 03-MAR-2010 10:13:39
Tracing not turned on.
Tns error struct:
ns main err code: 12560

TNS-12560: TNS: protocol adapter error
ns secondary err code: 0
nt main err code: 530

TNS-00530: Protocol adapter error
nt secondary err code: 126
nt OS err code: 0

In the error description section we can see the program name (In my case I was connecting through a web App; so it is w3wp.exe). The error reported above is really kind of generic stuff and there could be numerous reasons for such an error. The solutions for such a generic error may vary on a wide range and could even include different types of TIMEOUT settings that could be configured in the Sqlnet.ora file. Notice the highlighted text in the above error message which says “Tracing not turned on”. So, the bottom line being, collecting a detailed Sqlnet trace is always a good option to track down the actual issue.

First of all, we need to choose the component we would be tracing. Of the various components available like Client, Server, Listener etc. we would only focus on Client Side tracing.
For any component, you can invoke tracing by editing the component configuration file that corresponds to the component traced. The component configuration files are SQLNET.ORA , LISTENER.ORA , and NAMES.ORA etc.; for client side tracing we would only concentrate on SQLNET.ORA file which is typically found in: “%ORACLE_HOME%\Network\Admin” directory.

Below are the steps to configure Sql*Net verbose Client side tracing:
(1) Open the SQLNET.ORA file typically found in the installation location (or simply do a Search):

(2) Add the following parameters at the end of the file:

#CLIENT-SIDE SQL*NET TRACE PARAMETERS
#====================================
TRACE_UNIQUE_CLIENT = ON
TRACE_LEVEL_CLIENT = 16
TRACE_DIRECTORY_CLIENT = C:\temp
TRACE_FILE_CLIENT = SQLNetTrace
TRACE_TIMESTAMP_CLIENT = ON
#TRACE_FILELEN_CLIENT = 2048
#TRACE_FILENO_CLIENT = 2

Parameters prefixed with“#” are interpreted as comments and will not affect tracing.

If you want to change the location where the trace file will be saved modify the following two parameters:

(a) TRACE_DIRECTORY_CLIENT

Set this parameter to the folder where you want the trace file to be saved.

WARNING: Do not end the path with a “\”. This is not necessary and may prevent the trace file from being generated.

(b) TRACE_FILE_CLIENT

Set this parameter to the filename of the trace file that will be created. The actual trace filename may contain additional information appended to the end of the filename such as

SQLNetTrace_ _<#>.trc

Where_ _ is the application’s process id while it was running and <#> distinguishes different client connections established from the same process id (or session) to the database. This occurs since the
parameter TRACE_UNIQUE_CLIENT is set to ON.

The parameter TRACE_LEVEL_CLIENT=16 ensures that maximum trace information is logged.

NOTE: If you think the size of the trace file will exceed the free space on the drive where TRACE_DIRECTORY_CLIENT is saving the file, then uncomment the last two parameters which will have the following effect:

(a) TRACE_FILELEN_CLIENT - will create trace files of the size specified in kilobytes (KB).

(b) TRACE_FILENO_CLIENT - will write to multiple trace files up to the maximum size specified by
TRACE_FILELEN_CLIENT and then cycle through the files again overwriting previously written trace information.

The default values specified above for these two parameters will cycle the trace output between two trace files with a maximum size of 2MB each.

Once you have made the appropriate changes to the SQLNET.ORA file be sure to SAVE the file.

NOTE: If the application you are tracing is running from inside a web server environment, such as Microsoft’s Internet Information Server (IIS), you will need to RESTART THE WEB SERVER at this
point in order for these changes to be seen by the web server. This is due to the fact that web servers may cache the SQLNET.ORA file.

(3) Immediately run the application that uses one of the programmatic interfaces and generate the error.

(4) Immediately go back to the SQLNET.ORA file and turn tracing off by using any of the following methods:

(a) Modify the following parameter:

TRACE_LEVEL_CLIENT = OFF

(b) Remove all the tracing parameters you added to this file or

Save the changes to the SQLNET.ORA file.

(5) Retrieve the “.trc” file(s) from the location “C:\temp\SQLNetTrace\” or wherever you have saved the file(s) based on what was specified in the parameters TRACE_DIRECTORY_CLIENT and TRACE_FILE_CLIENT. If you did not specify a location please check the location of the directory where the application was run from or search your hard drive for all “.trc” files. Chec(1) Open the SQLNET.ORA file typically found in the following location:

ORACLE_BASE\ORACLE_HOME\Network\Admin (7.3.x, 8.1.x or later)
ORACLE_BASE\ORACLE_HOME\Net80\Admin (8.0.x)

(2) Add the following parameters at the end of the file:

Parameters prefixed with a “#” are interpreted as comments and will not
affect tracing.

If you want to change the location where the trace file will be saved
modify the following two parameters:

(a) TRACE_DIRECTORY_CLIENT

Set this parameter to the folder where you want the trace file to be
saved.

WARNING: Do not end the path with a “\”. This is not necessary and may
prevent the trace file from being generated.

(b) TRACE_FILE_CLIENT

Set this parameter to the filename of the trace file that will be
created. The actual trace filename may contain additional information
appended to the end of the filename such as

SQLNetTrace_ _<#>.trc

where is the application’s process id while it was running and
<#> distinguishes different client connections established from the
same process id (or session) to the database. This occurs since the
parameter TRACE_UNIQUE_CLIENT is set to ON.

The parameter TRACE_LEVEL_CLIENT=16 ensures that maximum trace
information is logged.

NOTE: If you think the size of the trace file will exceed the free space
on the drive where TRACE_DIRECTORY_CLIENT is saving the file, then
uncomment the last two parameters which will have the following
affect:

(a) TRACE_FILELEN_CLIENT - will create trace files of the size
specified in kilobytes (KB)

(b) TRACE_FILENO_CLIENT - will write to multiple trace files up
to the maximum size specified by
TRACE_FILELEN_CLIENT and then cycle
through the files again overwriting
previously written trace information

The default values specified above for these two paramters will
cycle the trace output between two trace files with a maximum size
of 2MB each.

Once you have made the appropriate changes to the SQLNET.ORA file be
sure to SAVE the file.

NOTE: If the application you are tracing is running from inside a web
server environment, such as Microsoft’s Internet Information
Server (IIS), you will need to RESTART THE WEB SERVER at this
point in order for these changes to be seen by the web server.
This is due to the fact that web servers may cache the SQLNET.ORA
file.

(3) Immediately run the application that uses one of the programmatic
interfaces and generate the error.

(4) Immediately go back to the SQLNET.ORA file and turn tracing off by using
any of the following methods:

(a) Modify the following parameter:

TRACE_LEVEL_CLIENT = OFF

(b) Remove all the tracing parameters you added to this file or

Save the changes to the SQLNET.ORA file.

(5) Retrieve the “.trc” file(s) from the location “C:\temp\SQLNetTrace\” or
wherever you have saved the file(s) based on what was specified in the
parameters TRACE_DIRECTORY_CLIENT and TRACE_FILE_CLIENT. If you did not
specify a location please check the location of the directory where the
application was run from or search your hard drive for all “.trc” files.
Check the size of the “.trc” file(s) and make sure they do not have a
size of 0 bytes but do have the current time and date. Zip the file up
and upload it to support.

Check the size of the “.trc” file(s) and make sure they do not have a size of 0 bytes but do have the current time and date. Zip the file up and upload it to the respective support group for further diagnosis.

SSIS Attunity Teradata Connector 1.0

Debarchans — Wed, 02 Sep 2009 05:36:00 GMT

Folks,

I just worked on an issue where one of our partners were not able to run SSIS Packages using the Attunity Teradata Connector 1.0 for SSIS. Details of the error message is documented below:

Connectivity to Teradata is fine, in SSIS designer we can also “Preview” the data and map the Columns. At runtime, BIDS reports: “[Teradata Source [22]]Error: The Teradata TPT registry key cannot be opened. Verify that the TPT API 12.0 for Windows x86 is installed properly.”

During my research it seemed following the pre-requisites before using this SSIS Connector:

v Teradata Parallel Transporter (TPT) version 12.0
v Teradata ODBC driver (version 12 recommended)
v If using a 64-bit platforms as a designer client (i.e.; using the Microsoft Business Intelligence Development Studio) both 64 and 32-bit clients should be installed.

I searched in partner's box and also did not see any registry keys and program directories relating to TPT (By Default they should be HKLMàSoftwareàTeradata and %Program Files%\TeraData). I suggested my partner to install Teradata Client Tools and Utilities as I believe TPT 12.0 APIs are the part of the Client Tools and Utilities. Customer however reported that still after the Client tools installation he is not able to get TPT 12.0.

I confirmed the fact that TPT API 12.0 indeed comes as a part of TTU (Teradata Tools and Utilities) installation, but for some reason we were not able to find it in the installer CD that was given to my partner by Teradata. We installed the TPT APIs separately and were able to execute the Package successfully. Teradata confirms that TPT APIs DOES COME as a part of TTU installer.

Anyway: Teradata should drive the issue further if the issue is because of Teradata installation pieces.

Phase 1 Update Dec 12, 2009:

I just went thru the Teradata Tools and Utilities installer and found that Typical install does not put in the TPT APIs required for SSIS. You need to do a Custom Install. I will shortly upload the screenshot of the installer with the required components selected in the Installer Wizard in Phase 2 Update.

Cheers !

Debs

SSIS SAP BI Connector 1.0

Debarchans — Wed, 02 Sep 2009 04:51:00 GMT

Folks,

I just handled a scenario with Customer using SAP BI Connector 1.0 for SSIS. I wanted to share the known issue I have encountered and the steps to resolve this. While the SAP BI side configurations continue to remain a sort of a black box for us, I am seeing that most Customers are having SAP consultants on their site who are making sure that SAP configurations are okay and it is sending data to the SSIS Engine. Below is the case study.

Case Study:

Symptoms:

========================

#. Using SSIS 2008 (10.0.2723 Sql 2008 SP1 CU3)

#. Using the SAP BI Connector 1.0 and SAP BI Source Task

#. When the SSIS Package is run from BIDS the Package hangs on the source task and never completes. In package Progress tab, the last message we see is "The component is waiting for a notification"

#. When run from command line using DTEXEC.exe we may or may not get this message. Sometimes it will throw the error depending on the environment:

In x86 environment the error message and the call stack would be:

System.OutOfMemoryException

at System.String.PadHelper(Int32 totalWidth, Char paddingChar, Boolean isRightPadded)

at Microsoft.SqlServer.Dts.SapBw.Connectivity.RFCStructure..ctor(RFCTableColumnCollection Columns)

at Microsoft.SqlServer.Dts.SapBw.Connectivity.RFCParameter.RetrieveColumnsByStructure(R3Connection Connection, String StructureName)

at Microsoft.SqlServer.Dts.SapBw.Connectivity.R3Connection.AddParametersAndTablesToUndefinedFunctionObject(RFCFunction& Dest, String Name)

at Microsoft.SqlServer.Dts.SapBw.Connectivity.R3Connection.CreateFunction(String Name)

at Microsoft.SqlServer.Dts.SapBw.Components.OHSExtractor.CheckMetadata()

at Microsoft.SqlServer.Dts.SapBw.Components.OHSExtractor.ExtractNow(Boolean InRuntimeMode, String GatewayHost, String GatewayService, String ProgramID, String ProcessChain, String DestinationName, String ExecutionMode, String PropertyRequestID, Int32 Timeout)

In x64 environment, the error message and the call stack would be:

Description: System.ArgumentOutOfRangeException: Non-negative number required.

Parameter name: totalWidth

at System.String.PadHelper(Int32 totalWidth, Char paddingChar, Boolean isRightPadded)

at Microsoft.SqlServer.Dts.SapBw.Connectivity.RFCStructure..ctor(RFCTableColumnCollection Columns)

at Microsoft.SqlServer.Dts.SapBw.Connectivity.RFCParameter.RetrieveColumnsByStructure(R3Connection Connection, String StructureName)

at Microsoft.SqlServer.Dts.SapBw.Connectivity.R3Connection.AddParametersAndTablesToUndefinedFunctionObject(RFCFunction& Dest, String Name)

at Microsoft.SqlServer.Dts.SapBw.Connectivity.R3Connection.CreateFunction(String Name)

at Microsoft.SqlServer.Dts.SapBw.Components.OHSExtractor.CheckMetadata()

Cause:

===================

#. There is a reported bug for this component in the Microsoft.SqlServer.SapBiComponents.dll.

BUG DETAILS:

============

BUG in SAP Data Connector 1.0

RFC#313260

Promoted RFC to QFE 329507

Bug #: 117545

Bug DB: Content Maintenance

#. This bug exists till Sql Server 2008 SP1 CU3 build:10.0.2723

Resolution:

==============

#. We have a private Fix from the Product group which is available at PSS.

#. The version of the Microsoft.SqlServer.SapBiComponents.dll would be upgraded to 10.0.2729.0

#. We tested this fix for both x86 and x64 systems and the issue was resolved.

HOWEVER, IT IS STRONGLY NOT RECOMMENDED TO USE SUCH PRIVATE BUILDS IN PRODUCTION. EVERYONE SHOULD WAIT FOR THE OFFICIAL RELEASE OF THIS FIX WHICH WOULD BE SHIPPED WITH SQL SERVER 2008 SP1 CU4!

HOWEVER, IF ANYONE IS FACING THE ISSUE AND WANT TO TEST OUT THE PRIVATE FIX, CONNECT WITH ME OFFLINE TO GET THE PATCHED DLL!

Steps to install the Fix:

===========================

Uncompress the attached fix-64bit-release.zip (or the 32 BIT one) to d:\tmp (or any other directory). Run “cmd” under administrator mode:

“gacutil /if d:\tmp\Microsoft.SQLServer.SapBiComponents.dll”

Gacutil.exe is a .Net utility you could find in your system disk.

If you see feedbacks like “Assembly successfully added to the cache”, it means the dll has been replaced:

Now the connector should work. To verify it, we will print a log at the beginning of extraction or loading: “This is the private build from PCU Main”.

Possible Errors and solutions during replacing the dll

=======================================================

1. “Access Denied”: Please make sure run “cmd” under administrator mode if your UAC is on.

2. “failed to validate strong name”: Since the dll is a private build, it has not been fully signed. We should set a flag to let .Net CLR skip the strong name validation. Run the following command:

“sn -Vr *” and then re-run the gacutil command. Sn.exe is also a .net utility you can find in your system disk.

3. If there are some other strange error happens after you replace the dll, make sure what you installed is the latest SAP BI Connector version (April 2009, not October 2008):

https://www.microsoft.com/downloads/details.aspx?FamilyID=b33d2c78-1059-4ce2-b80d-2343c099bcb4&displaylang=en

Phase 1 Update Dec 12, 2009:

CU4 for Sql Server 2008 SP1 is available now:

https://support.microsoft.com/kb/973602

This has the Dll patched !!

Cheers !

Debs

SSIS - An OLEDB Error Has Occurred

Debarchans — Mon, 13 Apr 2009 18:43:00 GMT

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.

+++

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 ''."

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

+++

Error:

0xC0202009 at Package, Connection manager "": 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/

+++

Error:

An OLE DB error has occurred. Error code: 0x80004005. An OLE DB record is available.The AcquireConnection method call to the connection manager "" 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

Good Old Connectivity Issue with Oracle in x64 Environment

Debarchans — Tue, 03 Feb 2009 18:46:00 GMT

When you try to develop an SSIS package in x64 Environment in BIDS that connects to a Oracle Database, you will invariabely run into connectivity issues if the installed Oracle Client tools version is 10.2.0.1 (x86). You will obviously need to install the 32-BIT version of Oracle Client to communicate with BIDS which is a 32-BIT application !

Subject:

ORA-12154 or ORA-6413 Running 32-bit Oracle Software on 64-bit Windows OS.

Applies to:

Oracle Net Services - Version: 8.1.7.0 to 10.2.0.2

Oracle Data Provider for .NET - Version: 8.1.7.0 to 10.2.0.2

Oracle Objects for OLE - Version: 8.1.7.0 to 10.2.0.2

Oracle Provider for OLE DB - Version: 8.1.7.0 to 10.2.0.2

Oracle ODBC Driver - Version: 8.1.7.0 to 10.2.0.2

Microsoft Windows XP (64-bit Itanium)

Microsoft Windows Server 2003 (64-bit Itanium)

Microsoft Windows XP (64-bit AMD64 and Intel EM64T)

Microsoft Windows Server 2003 (64-bit AMD64 and Intel EM64T)

Symptoms:

You are attempting to connect to the Oracle database from a Windows platform using one of the following programmatic interfaces

· ODBC

· OLEDB

· OO4O

· ODP.NET

After installing 32-bit Oracle client software on a 64-bit Windows operating system (OS) you receive one of the following errors:

ORA-12154: TNS:could not resolve the connect identifier specified

ORA-6413: Connection not open.

Cause:

64-bit Microsoft OS's install 32-bit applications into the following location

"C:\Program Files (x86)\..."

rather than the typical location of

"C:\Program Files\..."

This causes an existing networking bug to occur where the networking layer is unable to parse program locations that contain parenthesis in the path to the executable which is attempting to connect to Oracle.

The following bug has been filed to correct this behavior:

Bug 3807408 <https://metalink.oracle.com/metalink/plsql/showdoc?db=Bug&id=3807408>

NOTE: You will be able to view this bug details in the Metalinks site only if you have a Metalink login ID which comes with a support agreement with Oracle

Additional Information:

The reason you receive an ORA-12154 vs. an ORA-6413 is generally due to which programmatic interface you have chosen to use to connect to Oracle.

The ORA-12154 is the typical error seen when connecting with up-to-date interfaces using the latest version of the Oracle Call Interface (OCI):

· Oracle ODBC Driver

· Oracle Provider for OLE DB

· Oracle Objects for OLE

· Oracle Data Provider for .NET (ODP.NET)

· Microsoft's .NET Managed Provider for Oracle

The ORA-6413 is typical of using older interfaces which make legacy API calls such as Oracle's OCI Version 7 API:

· Microsoft ODBC Driver for Oracle

· Microsoft OLE DB Provider for Oracle

Solution:

To resolve this problem try the following solution:

The Best possible solution is to upgrade to Oracle 11G Release 1 version of Client tools (Build: 11.1.0.6.0) rather than applying the series of patches over the 10G client which may not produce desired results. The 11G version of the Client tools are tested and confirmed to include a FIX for the above error. If it is absolutely necessary to stick to the 10G version of the client (it shouldn't be), refer to the following:

For 32-BIT Oracle Client:

1. Install 10.2.0.2 upgrade - You need to select the correct Oracle Home path of previous 10.2.0.1 install

This install might fail at copying gacutil.exe...

To Fix this search for gacutil* in C drive and you will find gacutil.exe anc gacutil.exe.config files in some directory

Copy them to C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin

Some times you can't find gacutil.exe then copy this file from some other server

2. Rerun the previous install after copying gacutil files - Install will be successful, After that you need to install a patch(5383042) for 10.2.0.2

3. To install the patch for 10.2.0.2:

Create folder Patches in D:\oracle\product\10.2.0\client_1

Copy folder 5383042 from D:\Oracle32bit\Patchfor10202\p5383042_10202_WINNT TO D:\oracle\product\10.2.0\client_1\Patches

Go to command prompt

cd D:\oracle\product\10.2.0\client_1

set oracle_home=D:\oracle\product\10.2.0\client_1

cd D:\oracle\product\10.2.0\client_1\Patches\5383042>

D:\oracle\product\10.2.0\client_1\OPatch\opatch apply

The above command calls opatch.bat and you are in the patch folder so "apply" will apply the current patch folder you are in

It will prompt you for y/n ...say y

Create folder Patches in D:\oracle\product\10.2.0\client_1

Copy folder 5383042 from D:\Oracle32bit\Patchfor10202\p5383042_10202_WINNT TO D:\oracle\product\10.2.0\client_1\Patches

Go to command prompt

cd D:\oracle\product\10.2.0\client_1

set oracle_home=D:\oracle\product\10.2.0\client_1

cd D:\oracle\product\10.2.0\client_1\Patches\5383042>

D:\oracle\product\10.2.0\client_1\OPatch\opatch apply

The above command calls opatch.bat and you are in the patch folder so "apply" will apply the current patch folder you are in

It will prompt you for y/n ...say y

To check if the patch has been applied

D:\oracle\product\10.2.0\client_1\OPatch lsinventory

For 64-BIT Oracle Client:

1. Install 64bit 10.2.02 upgrade - Select the correct Oracle Home.

2. Install 64bit 10.2.03 upgrade - Select the correct Oracle Home.

3. Copy TNSNAMES folder from other servers to D drive.

4. Create an Environment variable TNS_ADMIN to path D:\TNSNAMES

However, It is strongly recommended to upgrade to Oracle 11G Release 1 version of Client tools (Build: 11.1.0.6.0) rather than applying the series of patches over the 10G client which may not produce desired results. The 11G version of the Client tools are tested and confirmed to include a FIX for the above error.

NOTE: This will allow you to create and run the package successfully from BIDS, but not as a Sql Job (in a x64 version of Sql Server). The reason being x64 version of Sql Server will always invoke x64 version of the DTEXEC.exe to run a job which will cause it to fail. We can confirm that by running the job successfully from command line using the 32-BIT DTEXEC.exe. (Running it from the C:\Program Files (x86) directory). So, to workaround this problem, we can choose one of the following solutions:

Solution 1:

Run the Job under the cmdExec subsystem and modify the command line so that the 32-BIT DTEXEC.exe is invoked to execute the job.

Phase 1 Update Dec 12, 2009:

Note: In Sql Server 2008 onwards you can still run the Job under Integration Services subsystem and use 32-BIT DTEXEC.exe. You need to go to "Execution options" in the Job Step properties and check "Use 32-BIT Runtime"

Solution 2:

Install the 64-BIT Oracle Client tools side by side with the 32-BIT one (Make sure you either apply the patch if you install 10G version or STRONGLY recommended to use the 11G Release 1 version)

Solution 3:

Modify the following Registry key to run the job under the Integration Services subsystem but to invoke the 32-BIT DTEXEC.exe to execute the package:

HKLM ->SOFTWARE->MICROSOFT->MSDTS->SETUP->DTSPATH. Change the value of the DEFAULT key to point to the 32-BIT DTEXEC.exe. Typically, under Default installation, that path will be C:\Program Files (x86)\Microsoft SQL Server\90\DTS\

NOTE: You will need to restart the Sql Server Agent Service for the registry change to take effect.

Cheers,

Debs !!