Installation Guide and Release Notes
Release 11.2.0.4.0 Production
This document provides information that supplements the Oracle Provider for OLE DB documentation.
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.
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/
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.