- Oracle Odbc Driver Configuration Fetch Buffer Size Error
- Oracle Odbc Driver Configuration Fetch Buffer Size For 2
- Oracle Odbc Driver Download
- Oracle Odbc Driver Configuration Fetch Buffer Size Formula
- Oracle Odbc Driver Configuration Fetch Buffer Size For Mac
- Oracle 11g Odbc Driver
Note:
Oracle ODBC Driver is supported only on the Linux x86 and Oracle Solaris on SPARC platforms.He set about designing a guitar amplifier around the new principle, and in 1972 the was released. He produced a number of custom variations on the Mark I through the late 1970s, with options including reverb, EQ, various speakers (most often Altec or ElectroVoice), jointed cabinets, and wicker grill. Oracle ODBC driver use to return wrong columnssize and bufferlength values through SQLColumns APIs for CHAR columns. (Bug 9414079) Oracle ODBC driver use to return SQLNODATAFOUND when SQLROWSETSIZE was set to more than the remaining rows. (Bug 9264668).
- To indicate Oracle's operating system authentication, use 'UID=/;'. The optimal buffer size for fetching columns. The driver optimizes fetching so that one fetch from the Oracle Server returns enough rows to fill a buffer of this size. Larger values tend to increase performance if you fetch a lot of data.
- When you use SAS/ACCESS Interface to ODBC to access Oracle, SAS might close unexpectedly. The problem occurs when you are accessing Oracle with the Oracle 11.2.x ODBC driver and the READBUFF= and INSERTBUFF= options have values greater than 100.
- UpToFirstFailure=Commit up to first failing statement (V7 ODBC behavior). AllSuccessful=Commit all successful statements (only when connected to an Oracle database; against other databases, same behavior as V7). FBS Fetch Buffer Size User-supplied numeric value (specify a value in bytes of 0 or greater). The default is 60,000 bytes.
This appendix provides information related to using Oracle ODBC Driver. It contains the following sections:
E.1 Features Not Supported
Oracle ODBC Driver does not support the following ODBC 3.0 features:
Interval data types
SQL_C_UBIGINT
andSQL_C_SBIGINT
C data type identifiersShared connections
Shared environments
The
SQL_LOGIN_TIMEOUT
attribute of SQLSetConnectAttrThe expired password option
Oracle ODBC Driver does not support the SQL functions listed in the following table:
String Functions | Numeric Functions | Time, Date, and Interval Functions |
---|---|---|
BIT_LENGTH | ACOS | CURRENT_DATE |
CHAR_LENGTH | ASIN | CURRENT_TIME |
CHARACTER_LENGTH | ATAN | CURRENT_TIMESTAMP |
DIFFERENCE | ATAN2 | EXTRACT |
OCTET_LENGTH | COT | TIMESTAMPDIFF |
POSITION | DEGREES
|
E.2 Implementation of Data Types
This section discusses the DATE
, TIMESTAMP
, and floating point data types.
DATE and TIMESTAMP
The semantics of Oracle DATE
and TIMESTAMP
data types do not correspond exactly with the ODBC data types with the same names. The Oracle DATE
data type contains both date and time information. The SQL_DATE
data type contains only date information. The Oracle TIMESTAMP
data type also contains date and time information, but it has greater precision in fractional seconds. Oracle ODBC Driver reports the data types of both Oracle DATE
and TIMESTAMP
columns as SQL_TIMESTAMP
to prevent information loss. Similarly, Oracle ODBC Driver binds SQL_TIMESTAMP
parameters as Oracle TIMESTAMP values.
See Also:
'DATE and TIMESTAMP Data Types' for information about the DATE and TIMESTAMP data types related to performance and tuningFloating Point Data Types
When connected to a release 11.1 or later Oracle Database, Oracle ODBC Driver maps the Oracle floating point data types BINARY_FLOAT
and BINARY_DOUBLE
to the ODBC data types SQL_REAL
and SQL_DOUBLE
, respectively. In earlier releases, SQL_REAL
and SQL_DOUBLE
mapped to the generic Oracle numeric data type.
E.3 Limitations on Data Types
Oracle ODBC Driver and Oracle Database impose limitations on data types. The following table describes these limitations:
Limited Data Type | Description |
---|---|
Literals | Oracle Database limits literals in SQL statements to 4000 bytes. |
SQL_LONGVARCHAR and SQL_WLONGVARCHAR | The Oracle limit for SQL_LONGVARCHAR data, where the column type is LONG , is 2,147,483,647 bytes. The Oracle limit for SQL_LONGVARCHAR data, where the column type is CLOB , is 4 gigabytes. The limiting factor is the client workstation memory. |
SQL_LONGVARCHAR and SQL_LONGVARBINARY | Oracle Database permits only a single long data column in each table. The long data types are SQL_LONGVARCHAR (LONG ) and SQL_LONGVARBINARY (LONG RAW ). Oracle recommends that you use CLOB and BLOB columns instead. There is no restriction on the number of CLOB and BLOB columns in a table. |
E.4 Format of the Connection String for the SQLDriverConnect Function
The SQLDriverConnect
function is one of the functions implemented by Oracle ODBC Driver. The following table describes the keywords that you can include in the connection string argument of the SQLDriverConnect
function call:
Keyword | Meaning | Value |
---|---|---|
DSN | ODBC data source name | User-supplied name This is a mandatory keyword. |
DBQ | TNS service name | User-supplied name This is a mandatory keyword. |
UID | User ID or user name | User-supplied name This is a mandatory keyword. |
PWD | Password | User-supplied name Specify This is a mandatory keyword. |
DBA | Database attribute | W implies write access
|
APA | Applications attributes | T implies that thread safety is to be enabled
|
RST | Result sets | T implies that result sets are to be enabled.
|
QTO | Query timeout option | T implies that query timeout is to be enabled.
|
CSR | Close cursor | T implies that close cursor is to be enabled.
|
BAM | Batch autocommit mode | IfAllSuccessful implies commit only if all statements are successful (old behavior).
|
FBS | Fetch buffer size | User-supplied numeric value (specify a value in bytes of 0 or greater).The default is 60,000 bytes. |
FEN | Failover | T implies failover is to be enabled.
|
FRC | Failover retry count | User-supplied numeric value. The default is 10. |
FDL | Failover delay | User-supplied numeric value. The default is 10. |
LOB | LOB writes | T implies LOBs are to be enabled.
|
FWC | Force SQL_WCHAR support | T implies Force SQL_WCHAR is to be enabled.
|
EXC | EXEC syntax | T implies EXEC Syntax is to be enabled.
|
XSM | Schema field | Default implies that the default value is to be used.
|
MDI | Set metadata ID default | T implies that the default value of SQL_ATTR_METADATA_ID is SQL_TRUE .
|
DPM | Disable SQLDescribeParam | T implies that SQLDescribeParam is to be disabled.
|
BTD | Bind TIMESTAMP as DATE | T implies that SQL_TIMESTAMP is to be bound as Oracle DATE .
|
NUM | Numeric settings | NLS implies that the Globalization Support numeric settings are to be used (to determine the decimal and group separator). |
E.5 Reducing Lock Timeout in a Program
Oracle Database waits indefinitely for lock conflicts between transactions to be resolved. However, you can limit the amount of time that Oracle Database waits for locks to be resolved. To do this, set the SQL_ATTR_QUERY_TIMEOUT
attribute of the ODBC SQLSetStmtAttr
function while calling this function before connecting to the data source.
E.6 Linking ODBC Applications
When you link the program, you must link it with the Driver Manager library, libodbc.so
.
E.7 Obtaining Information About ROWIDs
The ODBC SQLSpecialColumns
function returns information about the columns in a table. When used with Oracle ODBC Driver, it returns information about the Oracle ROWIDs associated with an Oracle table.
E.8 ROWIDs in a WHERE Clause
ROWIDs may be used in the WHERE
clause of an SQL statement. However, the ROWID value must be presented in a parameter marker.
E.9 Enabling Result Sets
Oracle reference cursors, also known as result sets, enable an application to retrieve data using stored procedures and stored functions. The following information describes how to use reference cursors to enable result sets through ODBC:
You must use the ODBC syntax for calling stored procedures. Native PL/SQL is not supported through ODBC. The following code sample identifies how to call the procedure or function without a package and within a package. The package name in this case is
RSET
.The PL/SQL reference cursor parameters are omitted when calling the procedure. For example, assume procedure
Example2
is defined to have four parameters. Parameters 1 and 3 are reference cursor parameters and parameters 2 and 4 are character strings. The call is specified as:
The following sample application shows how to return a result set by using Oracle ODBC Driver:
E.10 Enabling EXEC Syntax
If the syntax of the SQL Server EXEC
statement can be readily translated to an equivalent Oracle procedure call without requiring any change to it, then Oracle ODBC Driver can translate it if you enable this option.
The complete name of a SQL Server procedure consists of up to four identifiers:
Server name
Database name
Owner name
Procedure name
The format for the name is:
During the migration of Microsoft SQL Server database to Oracle Database, the definition of each SQL Server procedure or function is converted to its equivalent Oracle Database syntax and is defined in a schema in Oracle Database. Migrated procedures are often reorganized (and created in schemas) in one of the following ways:
All procedures are migrated to one schema (the default option).
All procedures defined in one SQL Server database are migrated to the schema named with that database name.
All procedures owned by one user are migrated to the schema named with that user's name.
To support these three ways of organizing migrated procedures, you can specify one of these schema name options for translating procedure names. Object names in the translated Oracle procedure call are not case-sensitive.
E.11 Supported Functionality
This sections provides information about the functionality supported by Oracle ODBC Driver. It contains the following sections:
E.11.1 API Conformance
Oracle ODBC Driver release 10.2.0.1.0 and higher supports all Core, Level 2, and Level1 functions.
E.11.2 Implementation of ODBC API Functions
The following table describes how Oracle ODBC Driver implements specific functions:
Function | Description |
---|---|
SQLConnect | SQLConnect requires only a DBQ , user ID, and password. |
SQLDriverConnect | SQLDriverConnect uses the DSN , DBQ , UID , and PWD keywords. |
SQLSpecialColumns | If SQLSpecialColumns is called with the SQL_BEST_ROWID attribute, then it always returns the ROWID column. |
SQLProcedures and SQLProcedureColumns | Refer to the information in the following row. |
All catalog functions | If the SQL_ATTR_METADATA_ID statement attribute is set to SQL_TRUE , then a string argument is treated as an identifier argument, and its case is not significant. In this case, the underscore (_) and the percent sign (%) are treated as the actual character, and not as a search pattern character. In contrast, if this attribute is set to SQL_FALSE , then it is either an ordinary argument or a pattern value argument and is treated literally, and its case is significant. |
Oracle Odbc Driver Configuration Fetch Buffer Size Error
SQLProcedures and SQLProcedureColumns
The SQLProcedures
and SQLProcedureColumns
calls have been modified to locate and return information about all procedures and functions even if they are contained within a package. In earlier releases, the calls only found procedures and functions that were outside of packages. The following examples and scenarios show what procedures or functions are returned if the SQL_ATTR_METADATA_ID
attribute is set to SQL_FALSE
.
Suppose that you have the following stored procedures:
When you look for %
or %%%%%%
, you get all eight procedures.
When you look for %_
or _%
, you get the following:
When you look for .
or .%
or %.%
or SQLPROC%.
or SQLPROC%.%
, you get the following:
When you look for %BAR
, you get the following:
When you look for .%BAR
or %.%BAR
, you get the following:
When you look for SQLPROC%
or .SQLPROC%
, you get the following:
E.11.3 Implementation of the ODBC SQL Syntax
If a comparison predicate has a parameter marker as the second expression in the comparison and the value of that parameter is set to SQL_NULL_DATA
with SQLBindParameter
, then the comparison fails. This is consistent with the null predicate syntax in ODBC SQL.
E.11.4 Implementation of Data Types
For programmers, the most important part of the implementation of the data types concerns the CHAR
, VARCHAR
, and VARCHAR2
data types.
For an fSqlType
value of SQL_VARCHAR
, SQLGetTypeInfo
returns the Oracle Database data type VARCHAR2
. For an fSqlType
value of SQL_CHAR
, SQLGetTypeInfo
returns the Oracle Database data type CHAR
.
E.12 Unicode Support
This section provide information about Unicode support. It contains the following topics:
E.12.1 Unicode Support Within the ODBC Environment
ODBC Driver Manager makes all ODBC drivers, regardless of whether or not they support Unicode, appear as if they are Unicode compliant. This allows ODBC applications to be written independent of the Unicode capabilities of underlying ODBC drivers.
The extent to which the Driver Manager can emulate Unicode support for ANSI ODBC drivers is limited by the conversions possible between the Unicode data and the local code page. Data loss is possible when the Driver Manager is converting from Unicode to the local code page. Full Unicode support is not possible unless the underlying ODBC driver supports Unicode. Oracle ODBC Driver provides full Unicode support.
E.12.2 Unicode Support in ODBC API
The ODBC API supports both Unicode and ANSI entry points using the W
and A
suffix convention. An ODBC application developer does not need to explicitly call entry points with the suffix. An ODBC application that is compiled with the UNICODE and _UNICODE preprocessor definitions will generate the appropriate calls. For example, a call to SQLPrepare
will be compiled as SQLPrepareW
.
The C data type, SQL_C_WCHAR
, was added to the ODBC interface to allow applications to specify that an input parameter is encoded as Unicode or to request column data returned as Unicode. The macro SQL_C_TCHAR
is useful for applications that need to be built as both Unicode and ANSI. The SQL_C_TCHAR
macro compiles as SQL_C_WCHAR
for Unicode applications and as SQL_C_CHAR
for ANSI applications.
The SQL data types, SQL_WCHAR
, SQL_WVARCHAR
, and SQL_WLONGVARCHAR
, have been added to the ODBC interface to represent columns defined in a table as Unicode. Potentially, these values are returned from calls to SQLDescribeCol
, SQLColAttribute
, SQLColumns
, and SQLProcedureColumns
.
Unicode encoding is supported for SQL column types NCHAR, NVARCHAR2, and NCLOB. In addition, Unicode encoding is also supported for SQL column types CHAR and VARCHAR2 if the character semantics are specified in the column definition.
Oracle ODBC Driver supports these SQL column types and maps them to ODBC SQL data types. The following table lists the supported SQL data types and the equivalent ODBC SQL data type:
SQL Data Types | ODBC SQL Data Types |
---|---|
CHAR | SQL_CHAR or SQL_WCHAR |
VARCHAR2 | SQL_VARCHAR or SQL_WVARCHAR |
NCHAR | SQL_WCHAR |
NVARCHAR2 | SQL_WVARCHAR |
NCLOB | SQL_WLONGVARCHAR |
E.12.3 SQLGetData Performance
The SQLGetData
function allows an ODBC application to specify the data type to receive a column as after the data has been fetched. OCI requires Oracle ODBC Driver to specify the data type before it is fetched. In this case, Oracle ODBC Driver uses information about the data type of the column (as defined in the database) to determine how to best default to fetching the column through OCI.
If a column that contains character data is not bound by SQLBindCol
, then Oracle ODBC Driver must determine if it should fetch the column as Unicode or as the local code page. The driver could always default to receiving the column as Unicode. However, this may result in as many as two unnecessary conversions. For example, if the data were encoded in the database as ANSI, then there would be an ANSI to Unicode conversion to fetch the data into Oracle ODBC Driver. If the ODBC application then requested the data as SQL_C_CHAR
, then there would be an additional conversion to revert the data to its original encoding.
The default encoding of Oracle Database Client is used when fetching data. However, an ODBC application may overwrite this default and fetch the data as Unicode by binding the column or the parameter as the WCHAR data type.
E.12.4 Unicode Samples
Because Oracle ODBC Driver itself was implemented using TCHAR
macros, it is recommended that ODBC application programs use TCHAR
in order to take advantage of the driver.
The following examples show how to use TCHAR
, which becomes the WCHAR
data type if you compile with UNICODE
and _UNICODE
:
Example E-1 Connection to Database
To use this code, you only need to specify the Unicode literals for SQLConnect
.
Example E-2 Simple Retrieval
The following example retrieves the employee names and the job tiles from the EMP
table. With the exception that you must specify TCHAR
compliant data to every ODBC function, there is no difference to the ANSI case. If the case is a Unicode application, then you must specify the length of the buffer to the BYTE length when you call SQLBindCol
. For example, sizeof(ename)
.
Example E-3 Retrieval Using SQLGetData (Binding After Fetch)
This example shows how to use SQLGetData
. There is no difference to the ANSI application in terms of Unicode-specific issues.
Example E-4 Simple Update
This example shows how to update data. The length of data for SQLBindParameter
has to be specified with the BYTE length, even in the case of a Unicode application.
Example E-5 Update and Retrieval for Long Data (CLOB)
This example may be the most complicated case to update and retrieve data for long data, like CLOB
, in Oracle Database. Because the length of data should always be the BYTE
length, the expression lstrlen(TCHAR data)*sizeof(TCHAR)
is needed to derive the BYTE
length.
E.13 Performance and Tuning
This section contains the following topics:
E.13.1 General ODBC Programming Guidelines
Apply the following programming guidelines to improve the performance of an ODBC application:
Enable connection pooling if the application will frequently connect and disconnect from a data source. Reusing pooled connections is extremely efficient compared to reestablishing a connection.
Minimize the number of times a statement must be prepared. Where possible, use bind parameters to make a statement reusable for different parameter values. Preparing a statement once and running it several times is much more efficient than preparing the statement for every
SQLExecute
.Do not include columns in a
SELECT
statement of which you know the application will not retrieve; especiallyLONG
columns. Because of the nature of the database server protocols, Oracle ODBC Driver must fetch the entire contents of aLONG
column if it is included in theSELECT
statement, regardless of whether the application binds the column or performs aSQLGetData
operation.If you are performing transactions that do not update the data source, then set the
SQL_ATTR_ACCESS_MODE
attribute of the ODBCSQLSetConnectAttr
function toSQL_MODE_READ_ONLY
.If you are not using ODBC escape clauses, then set the
SQL_ATTR_NOSCAN
attribute of the ODBCSQLSetConnectAttr
function or the ODBCSQLSetStmtAttr
function to true.Use the ODBC
SQLFetchScroll
function instead of the ODBCSQLFetch
function for retrieving data from tables that have a large number of rows.
E.13.2 Data Source Configuration Options
This section discusses the performance implications of the following ODBC data source configuration options:
Enable Result Sets
This option enables the support of returning result sets (for example,
RefCursor
) from procedure calls. The default is enabling the returning of result sets.Oracle ODBC Driver must query the database server to determine the set of parameters for a procedure and their data types in order to determine if there are any
RefCursor
parameters. This query incurs an additional network round trip the first time any procedure is prepared and executed.Enable LOBs
This option enables the support of inserting and updating LOBs. The default is enabled.
Oracle ODBC Driver must query the database server to determine the data types of each parameter in an
INSERT
orUPDATE
statement to determine if there are any LOB parameters. This query incurs an additional network round trip the first time anyINSERT
orUPDATE
is prepared and run.See Also:
Oracle Database SecureFiles and Large Objects Developer's Guide for more information on LOBsNote:
LOB data compression enables you to compress SecureFiles to gain disk, Input-Output, and redo logging savings. This reduces costs as compression utilizes space most efficiently and improves the performance of SecureFiles as compression reduces Input-Output and redo logging.LOB data encryption provides enhanced database security. While the encrypted data is available for random reads and writes, the data is more secure.
Data compression and encryption consumes some additional memory.
Bind TIMESTAMP as DATE
Binds
SQL_TIMESTAMP
parameters as the appropriate Oracle Database data type. If this option is set toTRUE
, thenSQL_TIMESTAMP
binds as the OracleDATE
data type. If this option is set toFALSE
, thenSQL_TIMESTAMP
binds as the OracleTIMESTAMP
data type, which is the default.Enable Closing Cursors
The
SQL_CLOSE
option of the ODBC function,SQLFreeStmt
, is supposed to close associated cursors with a statement and discard all pending results. The application can reopen the cursor by running the statement again without doing a SQLPrepare again. A typical scenario for this would be an application that expects to be idle for a while but will reuse the same SQL statement again. While the application is idle, it may want to free up any associated server resources.The OCI, on which Oracle ODBC Driver is layered, does not support the functionality of closing cursors. Therefore, by default, the
SQL_CLOSE
option has no effect in Oracle ODBC Driver. The cursor and associated resources remain open on the database.Enabling this option causes the associated cursor to be closed on the database server. However, this results in the parse context of the SQL statement being lost. The ODBC application can run the statement again without calling
SQLPrepare
. However, internally, Oracle ODBC Driver must prepare and run the statement all over. Enabling this option has a severe performance impact on applications that prepare a statement once and run it repeatedly.This option should only be enabled if freeing the resources on the server is necessary.
Fetch Buffer Size
Set the Fetch Buffer Size (
FetchBufferSize
) in theodbc.ini
file to a value specified in bytes. This value is the amount of memory needed that will determine how many rows of data Oracle ODBC Driver will pre-fetch at a time from an Oracle Database to the client's cache regardless of the number of rows the application program requests in a single query, thus improving performance.There will be an improvement in the response time of applications that typically fetch fewer than 20 rows of data at a time, particularly over slow network connections or from heavily loaded servers. Setting this too high can have an adverse effect on response time or consume large amounts of memory. The default is 64,000 bytes. You should choose an optimal value for the application.
When the
LONG
andLOB
data types are present, the number of rows pre-fetched by Oracle ODBC Driver is not determined by the Fetch Buffer Size. The inclusion of theLONG
andLOB
data types minimizes the performance improvement and could result in excessive memory use. Oracle ODBC Driver ignores the Fetch Buffer Size and only pre-fetches a set number of rows in the presence of theLONG
andLOB
data types.
See Also:
'Format of the Connection String for the SQLDriverConnect Function'E.13.3 DATE and TIMESTAMP Data Types
If a DATE
column in the database is used in a WHERE
clause and the column has an index, then there can be an impact on performance. For example:
In this example, an index on the HIREDATE
column could be used to make the query run quickly. However, because HIREDATE
is a DATE
value and Oracle ODBC Driver is supplying the parameter value as TIMESTAMP
, the query optimizer of Oracle Database must apply a conversion function. To prevent incorrect results (as might happen if the parameter value had nonzero fractional seconds), the optimizer applies the conversion to the HIREDATE
column resulting in the following statement:
However, this has the effect of disabling the use of the index on the HIREDATE
column. Instead, the server performs a sequential scan of the table. If the table has many rows, then this can take a long time. As a workaround for this situation, Oracle ODBC Driver has the connection option to bind TIMESTAMP
as DATE
. When this option is enabled, Oracle ODBC Driver binds SQL_TIMESTAMP
parameters as the Oracle DATE
data type instead of the Oracle TIMESTAMP
data type. This enables the query optimizer to use any index on the DATE
columns.
Note:
This option is intended only for use with Microsoft Access or other similar programs that bind DATE columns as TIMESTAMP columns. It should not be used when there are actual TIMESTAMP columns present or when data loss may occur. Microsoft Access runs such queries using whatever columns are selected as the primary key.E.14 Error Messages
Oracle Odbc Driver Configuration Fetch Buffer Size For 2
When an error occurs, Oracle ODBC Driver returns the native error number, the SQLSTATE
(an ODBC error code), and an error message. The driver derives this information both from errors detected by the driver and errors returned by Oracle Database.
Oracle Odbc Driver Download
Native Error
For errors that occur in the data source, Oracle ODBC Driver returns the native error returned to it by Oracle Database. When Oracle ODBC Driver or the Driver Manager detects an error, Oracle ODBC Driver returns a native error of zero.
SQLSTATE
For errors that occur in the data source, Oracle ODBC Driver maps the returned native error to the appropriate SQLSTATE
. When Oracle ODBC Driver or the Driver Manager detects an error, it generates the appropriate SQLSTATE
.
Error Message
For errors that occur in the data source, Oracle ODBC Driver returns an error message based on the message returned by Oracle Database. For errors that occur in Oracle ODBC Driver or the Driver Manager, Oracle ODBC Driver returns an error message based on the text associated with the SQLSTATE
.
Error messages have the following format:
The prefixes in brackets ([ ]) identify the source of the error. The following table shows the values of these prefixes returned by Oracle ODBC Driver. When the error occurs in the data source, the vendor
and ODBC-component
prefixes identify the vendor and name of the ODBC component that received the error from the data source.
Error Source | Prefix | Value |
---|---|---|
Driver Manager | [vendor] [ODBC-component] [data-source] | [unixODBC] [Driver Manager] Not applicable |
Oracle ODBC Driver | [vendor] [ODBC-component] [data-source] | [ORACLE] [Oracle ODBC Driver] Not applicable |
Oracle Database | [vendor] [ODBC-component] [data-source] | [ORACLE] [Oracle ODBC Driver] [Oracle OCI] |
Oracle Odbc Driver Configuration Fetch Buffer Size Formula
For example, if the error message does not contain the Ora
prefix shown in the following format, then error is an Oracle ODBC Driver error and should be self-explanatory.
If the error message contains the Ora
prefix shown in the following format, then it is not an Oracle ODBC Driver error.
Oracle Odbc Driver Configuration Fetch Buffer Size For Mac
Note:
Although the error message contains theOracle 11g Odbc Driver
Ora
prefix, the actual error may originate from one of several sources.If the error message text starts with the ORA-
prefix, then you can obtain more information about the error in Oracle Database documentation.