Oracle Provider for OLE DB (OraOLEDB)


Installation Guide and Release Notes

Release 11.2.0.4.0 Production

February 2013

Copyright (c) Oracle Corporation 2013

This document provides information that supplements the Oracle Provider for OLE DB documentation.

 

INSTALLATION AND SETUP NOTES

The Oracle Provider for OLE DB (OraOLEDB) provider, being a COM component, can have Only one version active on a machine at a time.

Note: During the OUI install, do not uncheck "Oracle Instant Client" on the "Available product Components" screen if you do not already have an Oracle 11gR1 client installed. Otherwise, the installation will fail with errors and the products will not work correctly later on.


Oracle Technology Network

For sample code, the latest patches, and other technical information on the Oracle Provider for OLE DB, go to http://otn.oracle.com/tech/windows/ole_db/ 

 

TIPS, LIMITATIONS AND KNOWN ISSUES

Performance

 

* To improve performance, do not use ADO method AppendChunk on LONG/LONG RAW

  columns. Instead, insert or update the entire LONG/LONG RAW column using

  the ADO AddNew or Update method.

 

* Use /*+ ... */ as the optimizer hint syntax with the OraOLEDB driver. The

  hint syntax, --+ ... is currently not supported.

 

Unsupported Parameter Types with OLE DB .NET Data Provider

 

* The Provider does not support LongVarChar, LongVarWChar, LongVarBinary, and

  BSTR IN/OUT and OUT parameter types with OLE DB .NET Data Provider because

  of a Microsoft's OLE DB .NET Data Provider known limitation.

 

Unsupported Datatypes

 

* The Trusted Oracle datatype MLSLABEL is not supported by the OraOLEDB driver.

 

* The provider does not currently support Object datatypes.

 

LOB Data Types

 

* The Command object currently errors out when updating LOBs on more than

  one row at a time.

 

  For example:

  UPDATE SomeTable SET LobCol = ? WHERE ...

  will error out if the UPDATE statement affects more than one row in the table.

  This restriction is limited to LOBs (BLOB/CLOB) and not LONGs (LONG/LONG RAW).

 

* As most LOB write (INSERT and UPDATE) operations involve multiple write

  operations within the provider, it is recommended that the transaction be

  enabled for such operations. Enabling transactions will allow consumers to

  rollback the entire write operation in the event of some failure. This is

  recommended when writing LOBs from the Command or the Recordset object.

 

DBLINK

 

To enable creating rowsets using queries containing Oracle Database Links, the

connection string attribute, DistribTx, should be disabled. Such rowsets are

currently limited to being read-only.

 

Transaction

 

* During a Local or Global Transaction, do not execute SQLs COMMIT, ROLLBACK or

  SAVEPOINT using the Command interface as they may affect the data consistency

  in the Rowsets. The same holds for executing DDLs (CREATE TABLE, ALTER VIEW,

  etc.) in this explicit transaction mode, as DDLs in Oracle perform an implicit

  Commit to the database. Execute DDLs only in the Auto-Commit mode.

 

* To enable Autonomous Transaction support, the connection string attribute,

  DistribTx, should be disabled. Using this feature, consumers can execute

  Stored Procedures having COMMITs and/or ROLLBACKs.

 

  Note that Commit/Rollback in a stored procedure should be performed with

  caution. As OraOLEDB provides transactional capability on rowsets, whose data

  is cached locally on the client-side, performing an explicit commit/rollback

  in a stored procedure, with an open rowset, could cause the rowset to be out

  of sync with the database. In these cases, all commits and rollbacks (aborts)

  should be performed from the client-side (con.Commit or con.Abort). The

  exception is if the user is making use of Autonomous Transactions in the stored

  procedure. By using this, the transaction in the stored procedure is isolated

  from the main one; thus allowing for localized commits/aborts.

 

  For more information on Autonomous Transactions, refer to Oracle11g "Advanced

  Application Developer's Guide" and "PL/SQL Language Reference".

 

Stored Procedures

 

For overloaded PL/SQL stored procedures and functions, the PROCEDURE_PARAMETERS

Schema Rowset returns the parameter information for only the first overloaded

stored procedure/function. This is because the OLE DB specification currently

does not have any provision for overloaded procedures/functions.

 

Case Sensibility

 

OraOLEDB currently expects the case of the objects specified in the Schema

Rowset Restriction to be exactly the same as in the database. That is, it

does not support passing "emp" to access the table "EMP".

 

  For example:

 

  Dim restrictions As Variant

  ...

  ' Schemarowset contains table EMP owned by SCOTT

  restrictions = Array(Empty, "SCOTT", "EMP", Empty)

  Set objRst = objCon.OpenSchema(adSchemaTables, restrictions)

  ...

  ' Schemarowset created with no rows

  restrictions = Array(Empty, "scott", "emp", Empty)

  Set objRst = objCon.OpenSchema(adSchemaTables, restrictions)

  ...

 

Microsoft Visual Basic 6.0 Notes

 

The Microsoft ActiveX Data Objects and Microsoft ActiveX Data Objects Recordset

libraries must be included as Project References.

 

Microsoft Visual C++ 6.0 Notes

 

OraOLEDB.h must be included in the relevant .cpp files in the VC++ project.

Also, #define DBINITCONSTANTS needs to be added to one of the .cpp files

in the project.