/ $Header: readme.doc 14-aug-2000.11:16:36 lvbcheng Exp $
/
/ Copyright (c) 1992, 2000 by Oracle Corporation
README FILE FOR PRODUCT Pro*C/C++ RELEASE 8.1.7
--------------------------------------------------------------------------------------------This file contains important information regarding Pro*C/C++ Version
8.1.7,
which is the precompiler release corresponding to 8.1.7 Oracle
database.
These notes are divided into the following five sections:
o Section 1 describes compatibility issues when migrating from earlier
releases of Pro*C/C++.
o Section 2 briefly describes the new functionality introduced in this
release of Pro*C/C++.
o Section 3 describes the known bugs associated with this release.
o Section 4 describes the bugs that have been fixed in this release.
o Section 5 lists restrictions and limitations in Pro*C/++ 8.1.6. It
also
provides some usage tips for the new host variable types introduced
in
this release and describes a few other miscellaneous issues.
SECTION 1: COMPATIBILITY AND MIGRATION ISSUES
----------------------------------------------------------------------------------------Desupport Notification for V6 Compatibility Behavior
---------------------------------------------------With Oracle7, Oracle offered a Version 6 [V6] Compatibility flag that
allowed
application developers developing Oracle7 applications to emulate Oracle6
behavior. Beginning with the release of Oracle 8.0.3, users are cautioned
that
the Version 6 compatibility flag is being desupported effective
immediately in
all of the Oracle8 products including PL/SQL8, all the Oracle
Precompilers,
the Oracle8 Oracle Call Interface, SQL*Module, and SQL*PLUS. The
desupport of
the V6 compatibility flag is consistent with Oracle's policy of
supporting
backwards compatibility and behavior from one version release upgrade to
another i.e. from Oracle6 to Oracle7 but not for more than one version
release upgrade.
Specifically, the V6 Compatibility flag emulated the following aspects of
Oracle6 behavior with Oracle7:
o String literals are fixed length in Oracle7 but are treated as
variable
length with the V6 flag
o PL/SQL Local char variables are fixed length in Oracle7 but are
treated
as variable length with the V6 flag
o Return value of SQL Functions (e.g. USER) are fixed length characters
in
Oracle7 but are treated as variable length characters with the V6
flag
o Select/Fetch of a NULL with no indicator raises an ORA-1405 error
with
Oracle7 but returns no error with the V6 flag
o SQL group function is called at FETCH time with Oracle7 but is called
query execution time with the V6 flag
o Describe of a fixed length string returns Type=96 with Oracle7 but
returns Type=1 with the V6 flag
All of these behaviors are being desupported with the desupport of the V6
Compatibility Flag with Oracle8.
SQLLIB Migration to use Oracle 8.1 OCI
---------------------------------------Beginning with release 8.1, SQLLIB uses V8OCI to communicate with the
database. This change gives rise to the following compatibility issues:
o To improve performance when executing embedded PL/SQL, all host
variables must be initialized prior to executing the PL/SQL block.
This is true regardless of the underlying mode (IN, IN/OUT, OUT) of
the variable from the PL/SQL perspective. Not initializing a bind
variable will result in an error at execute time.
o Applications using the OCI interoperability functions sqlcda() and
sqlcur() (SQLCDAFromResultSetCursor and SQLCDAToResultSetCursor) must
call either sqllda() or sqlld2() (SQLLDAGetCurrent or SQLLDAGetNamed)
immediately after establishing a connection through embedded SQL.
For example:
sql_cursor curvar;
Lda_Def lda;
Cda_Def cda;
EXEC SQL CONNECT :uid IDENTIFIED BY :pwd;
/* This function must be executed immediately after connecting */
SQLLDAGetCurrent(&lda);
/* Continue with logic to allocate, open a fetch using curvar */
EXEC SQL ALLOCATE :curvar;
EXEC SQL EXECUTE
BEGIN
open :curvar for select ename from emp order by empno;
END;
END-EXEC;
EXEC SQL FETCH :curvar INTO :name;
sqlcda(&cda, (dvoid *)&curvar, &code);
ofetch(&cda);
This will put the connection in "v7 mode" so the conversion between
a precompiler cursor variable an a v7 Cda_Def is possible. Note that
Universal Rowids (OCIRowid *) may not be used if the connection is in
V7 mode.
o XA and V8 OCI
Do not mix a Pro*C XA application with calls to the V8 OCI library.
Such usage is not recommended since a Pro*C XA application is
connected in V7 which does not operate well when V8 connections
exist simultaneously.
o ROWIDs
A describe (EXEC SQL DESCRIBE SELECT LIST . . .) for a ROWID column
now returns type SQLT_RDD instead of SQLT_RID.
In general, programmers should use Universal Rowids (type OCIRowid *)
in all new development. This will enable the underlying table to be
migrated from a heap table to an index organized table with no change
to application code.
o When a null is fetched and an indicator variable is present, the
contents of the corresponding host variable is untouched. You
must check the value of the indicator variable to determine the
NULL/NOT NULL status.
o When a null is selected or fetched into a host variable with no
corresponding indicator variable, the query processing does not
stop. Subsequent rows are still retrieved into the users host
variables and the rows processed count reflects the total number
of rows selected/fetched. It cannot be used to determine which
row contains a NULL value.
Compatibility between 32 bit and 64 bit implementations
------------------------------------------------------On platforms which support both 32 bit and 64 bit implementations, you
must re-precompile your applications which include sqlca via an EXEC SQL
INCLUDE statement before linking with the 64 bit binaries. For
applications
which include sqlca.h via the #include preprocessor statement, you must
recompile to include the 64 bit sqlca.h before relinking with the 64 bit
binaries.
In the future, to support generated code compatibility across
implementations,
only one version, the 64 bit version, of sqlca.h may be supplied on ports
which support both 32 bit and 64 bit binaries.
SECTION 2: NEW FUNCTIONALITY
--------------------------------------------------------1. New Non-Object Functionality Introduced between Releases 8.0.3 and
8.0.5.
a. Expiring Passwords
Pro*C/C++ now provides the ability for an application to change the
password of a user at runtime via syntactic extensions to the
Embedded
SQL Connect Statement.
b. Arrays of Structs
Arrays of Structs and Pointers to Arrays of Structs are now
supported
as host variables and indicator variables in Embedded SQL.
c. Large Object (LOB) and BFILE Support
BLOBs, CLOBs, NCLOBs and BFILEs can be manipulated by declaring
host
variables to be of a specific LOB Locator type. These host
variables
can then be used in Embedded SQL to refer to LOBs in the server.
d. Support for NCHAR data
NCHAR data is now fully supported by the kernel. Previous releases
of the precompiler supported this datatype with the NLS_LOCAL
option.
For new applications, users are strongly encouraged to rely on the
database support and accordingly set NLS_LOCAL=NO during
precompilation.
e. User Callable SQLLIB Functions
The existing user-callable sqllib functions have been given longer,
more descriptive names. For compatibility reasons, the old names
are still accepted. Users are strongly encouraged to use the new
names in all new applications.
f. User Settable Runtime Context Options
The runtime context has options which are set to default values
when it
is created and allocated, A generic mechanism for setting specific
runtime context values has been introduced. Only a couple of
options
are currently supported, however.
g. Support for SYSDBA and SYSOPER Connect Modes
In previous versions of Oracle, the user could connect with SYSDBA
privileges by specifying:
EXEC SQL CONNECT :<uid> IDENTIFIED BY :<pwd> ;
where <uid> is a host variable containing "SYS" and <pwd> is a host
variable containing "CHANGE_ON_INSTALL". The SYSDBA privileges are
no longer available by default by using the above, thus Pro*C/C++
now
supports an optional IN MODE clause in the embedded CONNECT
statement
where the user can specify either SYSDBA or SYSOPER mode.
h. New WHENEVER action 'DO CONTINUE'
The 'DO CONTINUE' action behaves much like a 'DO BREAK'. In the
latter
case, an explicit 'break' statement is issued. The 'DO CONTINUE'
action
causes a 'continue' statement to be generated. This differs from
the
'CONTINUE' action which just results in the continuation of the
program.
2. New Non-Object Functionality for Release 8.1.3.
a. Embedded SQL LOB Interface
A convenient, easy to use Embedded SQL LOB Interface has been
provided
to give application developers enhanced support for LOBs that is
meant
to provide the same functional support for LOBs as the Oracle OCI
API or
PL/SQL DBMS_LOB package.
b. ANSI Dynamic SQL Interface
Pro*C/C++ now has a new implementation of Dynamic SQL that has been
derived from the ANSI Standard. The ANSI Dynamic SQL Interface has
enhancements over the Oracle Dynamic SQL Method 4 Interface. The
ANSI
Dynamic SQL Interface supports all Oracle types including Objects,
Arrays of Structs, Cursor Variables and LOBs.
c. DML Returning Clause
Pro*C/C++ now supports the use of the DML Returning Clause on the
INSERT, UPDATE and DELETE Embedded SQL DML statements.
d. Support for Universal ROWID
Pro*C/C++ now provides a mechanism to ALLOCATE and FREE Rowid
Descriptors that are compatible with both Physical Rowids
(associated
with heap tables) and Logical Rowids (associated with index
organized
tables). Users declare Rowid Descriptors as OCIRowid *. These
Descriptors may then be used as host variables in Embedded SQL
statements. Oracle recommends use of rowid descriptors in all new
developmeent.
e. Extended Support for Runtime Contexts
Extensions to the Embedded CONTEXT USE statement now allow for a
developer to specify a specific runtime context or to default to a
global SQLLIB runtime context instead.
f. External Procedure Support
External Procedures written in Pro*C/C++ are now callable from
PL/SQL.
A REGISTER CONNECT Embedded SQL statement has been introduced.
This
new statement is used instead of a CONNECT statement in the
External
Procedure to define the current unnamed connection for the Global
SQLLIB Runtime Context.
g. Support for Pre-Fetching
Oracle supports the notion of Pre-Fetching a number of rows when a
query is executed. This increases performance by eliminating the
need for a server roundtrip when the rows are subsequently fetched.
Pre-Fetching may be enabled in Pro*C/C++ by using the new command
line
option, PREFETCH = 0 .. 65535. The PREFETCH value indicates the
number of rows that are pre-fetched when the query is executed
(where
0 means prefetching is disabled). The option may be used in a
configuration file, on the command line or inline.
3. New Non-Object Functionality for Release 8.1.4.
a. Calling Stored Java Procedures
A new Embedded SQL CALL statement has been introduced in Release
8.1.4
of Pro*C/C++ to provide application developers the ability to
invoke
stored Java (and PL/SQL) procedures directly without having to use
an
Embedded PL/SQL anonymous block.
4. New Non-Object Functionality for Release 8.1.5.
a. Precompiled Header Capabilities
Starting with release 8.1.5, Pro*C/C++ allows the user to
precompile a
header file and store the contents of that precompilation into a
special
binary file that can be instantiated in place of actually
precompiling
the header file when included via the #include directive during the
precompilation of an ordinary Pro*C/C++ program or another header
file.
A new command line option (called 'header') is provided to both
enable
the new precompiled header mechanism and specify the file extension
to
use when generating and searching for the binary files.
5. New Non-Object Functionality for Release 8.1.6
a. Fully Integrated Debugging Capabilities
Beginning with release 8.1.6, the behavior of the LINES={YES|NO}
option
has changed. Now, when LINES=YES is specified, a #line
preprocessor
directive is generated after every line of generated code in the
output
program. This enables developers using debuggers such as GDB or
IDEs
such as the Microsoft Visual Studio for C++ to debug their
application
programs by viewing the Pro*C/C++ source program instead of by
stepping
through the generated code.
6. New Object Functionality for Pro*C/C++ Version 8.0.3 through 8.0.5.
a. Support For Object Types
Pro*C/C++ supports the manipulation of host variables of object
types
via Embedded SQL and PL/SQL statements. Users must run OTT (Object
Type
Translator) to generate typedefs of C structs for named types
defined
in the Oracle8 database, and declare variables of these types (or
pointers to these types) in the Pro*C/C++ application program to
correspond to object instances in the Oracle8 database.
b. Use of OTT-generated Type Files
An additional Pro*C/C++ input file, the INTYPE file, is specified
on the command-line to give the precompiler necessary information
about object types. This file is generated by OTT during
translation
of object types in an Oracle8 database to typedefs of C structs.
c. Support for Navigational Operations
A Navigational Interface for providing operations for Creating
Objects,
manipulating Object References, Setting and Getting Attributes of
Objects as well as controlling the Pinning and Unpinning of Objects
in
the Object Cache has been provided.
NOTE: A REF needs to be allocated in all instances where it will be
returned. Specifically, in an EXEC SQL OBJECT CREATE with RETURNING
REF call, the host variable following 'RETURNING REF INTO' must
contain a previously allocated REF (via EXEC SQL ALLOCATE :hv).
7. New Object Functionality for Pro*C/C++ Release 8.1.3.
a. The Navigational Interface for release 8.1.3 has been enhanced
since
its introduction in 8.0.3 to include the ability to Get and Set LOB
and Collection Attributes of an Object Type as well. The optional
FOR UPDATE clause in an EXEC SQL OBJECT DEREF statement has also
been
enhanced with an optional NOWAIT.
b. Enhanced Support for Collections
A new Embedded SQL Interface has been provided to allow for the
ability to access, modify and update the individual elements of a
Collection. This interface is intended to provide similar
functional
support for Collections that the OCI API currently provides in a
convenient, easy to use Embedded SQL sytle.
8. Interoperation of Pro*C/C++ 8.1.6 programs with the Oracle8 OCI API
a. New OCI Interoperability Functions
New library routines SQLEnvGet() and SQLSvcCtxGet() are introduced
to support interoperation of 8.1.6 Pro*C/C++ programs with 8.1 OCI.
The 8.1 OCI environment handle and the 8.1 OCI service context
handle
for a database connection established in Pro*C/C++ may be obtained
via
the above routines.
Demo programs of most new functionality introduced between Releases
8.0.3 and 8.1.6 of Pro*C/C++ can be found in the Pro*C/C++ demo
directory
along with supporting SQL scripts. Included are
o
o
o
o
o
o
o
ansidyn1
ansidyn2
objdemo1
coldemo1
lobdemo1
sample4
navdemo1
-
Use
Use
Use
Use
Use
Use
Use
of
of
of
of
of
of
of
the ANSI Dynamic SQL Interface in Pro*C/C++
the ANSI Dynamic SQL Interface in Pro*C/C++
Object types in Pro*C/C++
Collection types in Pro*C/C++
LOB types in Pro*C/C++
the Embedded SQL LOB Interface in Pro*C/C++
the Navigational Interface in Pro*C/C++
The code for these programs can be found in
$ORACLE_HOME/precomp/demo/proc
with supporting SQL scripts provided in the
$ORACLE_HOME/precomp/demo/sql
directory.
SECTION 3: BUGS KNOWN TO EXIST IN Pro*C/C++ RELEASE 8.1.6
----------------------------------------------------------------------------------------------------------------773318
When warnings and errors are both required, the warning might be
lost because OCI only provides the error in this case.
SECTION 4: BUGS FIXED IN THIS RELEASE
------------------------------------------------------------------------Bugs Fixed between Release 8.1.6 and Release 8.1.7
==================================================
753504
Pro*C/C++ could not #include header file without extension
When #include header file without extension, Pro*C/C++ will
give precompile-time error.
780572
error.
Usage of objects in XA application generated random runtime
When object functionality was used in XA applications, it
generated random execution error. This was caused by not having
error
handle correctly initialized for runtime processing. With the fix,
meaningful error message "SQL-02139: Unable to get the OCI handles"
gets generated.
994713
PROC dumped core when invalid syntax was used.
PROC dumped core when invalid syntax was used.
e.g. For the following invalid syntax,
short aj = 0 ;
EXEC SQL OBJECT SET NAME OF :person:aj TO :c INDICATOR :c_ind;
PROC with the fix generates precompiler
error as:
Semantic error at line 246, column 43, file t994713.pc:
EXEC SQL OBJECT SET NAME OF :person:aj TO :c INDICATOR :c_ind;
..........................................1
1066827 DML statement against non-existing record caused defunct process
DML statement against the record which does not exist might cause
defunct process and for each NOT FOUND condistion will make
unnecessary
round-trip call to the server resulting in poor performance.
1071050 Use of "ORDER BY" in subquery led to a precompiler error
When "ORDER BY" was used in the subquery it lead to
precompiler error as it was not supported. It is supported
in sql from 8.1 onwards and hence should be supported
in the corresponding proc versions.
For example :The statement
select ename,sal,comm
into...
(select ename,sal,comm from emp order by ename)
where rownum < 10
failed in proc giving a syntax error.
With the fix the "ORDER BY" in the subqueries is accepted
as valid syntax.
1103175 SQLCA.SQLWARN 3RD ELEMENT IS NULL INSPITE OF THE 1ST ELEMENT
SHOWING 'W'
Third element of the sqlwarn array not turned on when null data
was queried.
1117747 Application generated ORA-2111 during runtime.
Whenever format buffer pointer of SQLDA1 was initialized in the
application, SQLLIB generated ORA-2111 error due to freeing this
buffer format of mismatched size. With the fix, buffer pointer
is freed only if the space was allocated by SQLLIB.
1125748 Core dump occurred in some cases of dynamic sql statements
Core dump occurred in some cases of dynamic sql statements.
When number of columns fetched were bigger than the allocated
number of columns, F variable had the negative value. This
value was not correctly converted for comparisions in some
compilers (like on AIX). With the fix, correct comparision
is being done.
1151788 GPF ON ANSI DYNAMIC FETCH WHEN DATA IS TYPE 5 AND
GPF may occur on an ANSI dynamic fetch when data is
and the reported length of that data field is the
length
or the length is defaulted to the declared length
variable.
LEN IS MAX
type 5
allocated
of the host
1171054 GPF possible for XA, V7 connects and use of SQLSvcCtxGet due to
sqlcap
A dangling sqlcap pointer (sqlca pointer for the runtime context)
may cause a GPF to occur if the sqlcap is allowed to dangle.
GPF ON ANSI DYNAMIC FETCH WHEN DATA IS TYPE 5 AND LEN IS MAX.
1178313 Wrong values in "C" VARIABLE IN SQLDA generated core dump.
Wrong values in "C" VARIABLE IN SQLDA generated core dump.
With the fix, C is going to hold the truncated length
(i.e. MAX_VNAME_LEN) of the corresponding column name,
whenever the length of column name is bigger than
MAX_VNAME_LEN.
1239856 PROC generated precompiler error, when "sizeof" was used.
When "sizeof" was used in resolving the type of a host variable,
PROC generated a precompiler error. With the fix warning is
being
generated for the same host variable stating that "sizeof"
expression is NOT actually being evaluated.
e.g.
char dst[1024] ;
char dyn_statement[sizeof(dst)];
EXEC SQL VAR dyn_statement IS STRING(1024);
it will generate following warning message:
Semantic error at line 61, column 27, file t1239856.pc:
char
dyn_statement[sizeof(dst)];
..........................1
PCC-W-02314, cannot evaluate constant sizeof expression
Note: In some scenerios the application may not work as
intended. So, it is highly recommended to avoid the use of
"sizeof" in the type of any host variables.
1285882 XA client with V8OCI connection generated ORA-3114
When XA application used XA connection and V8OCI
connection, runtime generated ORA-3114 error. In
some cases the inserted data was lost, creating the
bad execution behavior. With the fix, appropriate
runtime data structures get initialized whenever
V8OCI and XA connection is used together in the
application.
1328685 ORA-1012 got generated on FETCH
PROC runtime generated ORA-1012 while doing the FETCH.
With the fix, FETCH executes successfully.
1343460 PROCOB runtime generated ORA-1727 error.
PROCOB runtime generated ORA-1727 error while using dynamic
sql statements. The error was flagged by V8 OCI to suggest
that precision and scale were not correctly setup. With the
fix, ORA-1727 no longer gets generated.
Bugs Fixed between Release 8.1.5 and Release 8.1.6
==================================================
927164
ORA-2103 occurred, with RELEASE_CURSOR=YES HOLD_CURSOR=NO
When application was built using RELEASE_CURSOR=YES, and
HOLD_CURSOR=NO options, at runtime ORA-2103 occurred. The error
was caused due to freeing some elements of cursor, even though it
was trying to re use it. Appropriate conditions has been placed
to fix this problem.
922250
Missing '\' for line continuation in generated file
Pro*C/C++ generated bad code by missing '\' as a line
continuation
character in some cases.
909074
Can not use upper case filename to open lowercase include file
Pro*C/C++ generated a 'PCC-S-02015, unable to open include file'
error when using upper case filenames to open an include file
that
was actually in lowercase.
872814
EXEC SQL READ for NCLOB data returns ORA-24806 error
Applications generated an 'ORA-24806: LOB form mismatch' when
using
NCLOBs in embedded SQL LOB READ (and WRITE) statements.
850965
Problem mixing pointer/non-pointer host/indicator structs
Pro*C/C++ could not process pointer indicator structs when mixed
with a corresponding non-pointer host structure. For example
typedef struct { .. } hst;
typedef struct { .. } ind;
hst h;
ind i, *ip = &i;
EXEC SQL SELECT .. INTO :h:ip FROM ..;
The mixing of a host/indicator struct pair where one was a
pointer
and the other was not would result in semantic precompilation
errors.
826057
ANSI dynamic SQL option type_code fails on 64 bit ports
The TYPE_CODE option, when set to the value ANSI and used with
ANSI dynamic SQL gave incorrect results on 64 bit platforms.
821874 Use of the AT clause caused extra file descriptor usage for
SQLUS.MSB
Whenever the AT clause was used during a CONNECT statement, the
SQLUS.MSB message file was getting opened, which was not
necessary.
Now, opening of SQLUS.MSB has been delayed until an error occurs.
791384
Append of a LOB to a NULL LOB returns nondescript error message
An APPEND of a LOB to a NULL LOB is an error. However, the error
message returned by SQLLIB did not correctly describe the
situation.
764996
Unable to use a table alias in an INSERT statement
Use of a a table alias in any INSERT statement caused a syntactic
error. For example..
EXEC SQL INSERT INTO persons p VALUES ..
RETURNING .. INTO .. ;
The table alias, 'p', was not accepted by Pro*C/C++ with a syntax
error being the result.
761892
Pro*C/C++ does not recognize connection qualifiers
Pro*C/C++ was not able to parse the use of connection qualifiers
in a table reference. For example, the following
EXEC SQL SELECT .. INTO .. FROM sys.dual@v7bug.world@q1;
would result in syntactic errors on the use of the '@' signifying
the connection qualifier.
693939
SQL
Blank padded character types were not padded with ANSI dynamic
Character, ANSI varying character and ANSI fix character types
were
not blank padded when used in ANSI dynamic programs.
They are
now
blank padded and the returned length field is undefined.
690984
HEX
Pro*C/C++ sees host field length as 0 if length is specified in
Pro*C/C++ failed to correctly process the length of a char or
varchar
host variable that was declared using a Hex (or Octal) constant.
For
example, the length of a variable, char x[0x40], was computed to
have
a value of zero and would thus fail if used inside a SQL
statement.
606462
CHAR variable equivalenced to CHARF does not pick up length of 1
Type equivalencing a single char variable to CHARF (ie; 'char x';
followed by 'exec sql var x is charf;' - note the lacking length
specification) caused an incorrect length of 0 (rather than 1) to
be assigned to the host variable which resulted in bad data when
used in an embedded SQL statement.
319566
Multi-line ANSI style comments (--) fail with PCC-S-2201
Syntactic errors resulted from the use of multiple ANSI style SQL
hints in an embedded SQL statement. For example
EXEC SQL SELECT --+ hint comment 1
--+ hint comment 2
... INTO ... FROM ...;
would produce syntactic error messages during precompilation.
workaround was to use the /*+ .. */ hint format as an
alternative.
A
Bugs Fixed between Release 8.1.3 and Release 8.1.5
==================================================
701934
Pro*C dumps core using improper Indicator Variable with an Object
Pro*C would dump core when using an indicator variable whose type
was not generated by the Object Type Translator with a host
variable
of some Object type (ie; one whose type was generated by OTT).
Bugs Fixed between Release 8.0.5 and Release 8.1.3
==================================================
544522
Pro*C did not accept arithmetic expressions in bind variables
Pro*C would not accept bind variable expressions that involved
the use of arithmetic expressions. For example
EXEC SQL UPDATE tab SET col = :x[i+1];
Pro*C would raise an error on the i+1 expression saying that
the expression type did not match its usage.
Pro*C will now accept certain arithmetic expressions with the
restriction that ONLY the +, -, *, / and % operators be used.
692782
Pointers to SQL_CURSOR variables don't work in ALLOCATE or FREE
Using host variables of type 'SQL_CURSOR *' in either the EXEC
SQL ALLOCATE or FREE statements would result in a segmentation
fault at runtime. Only non-pointer SQL_CURSOR host variables
would work correctly in these statements. Note that using host
variables of type 'SQL_CURSOR *' in other statements such as
FETCH or CLOSE would work without any problems.
692548
Pro*C could not handle Pointer to Struct containing Arrays
If a host variable used in a SELECT or FETCH statement was a
pointer to a struct that contained arrays, only 1 row would
be retrieved regardless of the array size(s). This could
cause a SQL-2112: SELECT .. INTO returns too many rows for
the SELECT statement case. Use of a FOR clause could work
around the problem for FETCH cases, but FOR clauses are not
permitted in SELECT statements. An example follows..
struct foobar { int empno[14]; } a, *b;
b = &a;
EXEC SQL SELECT empno INTO :b FROM emp;
The SQL-2112 error would result. SELECTing into :a would
work just fine. Note that the fact that the struct is a
NAMED struct is relevant. Use of an UNnamed struct would
not result in an error. An unnamed struct pointer would,
in fact, work properly in these cases.
668920
ORDER BY clauses in CURSOR and MULTISET subqueries not accepted
Pro*C would generate syntactic errors if an ORDER BY clause
appeared as part of a CURSOR or MULTISET subquery. For example,
EXEC SQL SELECT CURSOR(SELECT ename FROM EMP
WHERE deptno = :deptno
ORDER BY ename)
FROM DUAL;
ORDER BY clauses are optional and should be allowed in either a
CURSOR or MULTISET subquery.
Bugs Fixed between Release 8.0.4 and Release 8.0.5
==================================================
642112
valid
SQLLIB returned 1012 (not connected) even when connection was
When the connection was not made through embedded sql connect
statement, sqllib returned ORA-01012 error message.
638215
REF indicators did not work properly
REF indicators were not properly set. Thus a statement such as:
EXEC SQL SELECT ref_column
INTO :ref_hostvar:ref_indvar FROM tab WHERE .. ;
would have returned an ORA-1405.
636898
A memory leak may occur for a connect/disconnect pair in MT apps
Multi-threaded applications (i.e. those precompiled with
threads=yes
and who have executed EXEC SQL ENABLE THREADS) may observe a
memory
leak if an EXEC SQL CONNECT and EXEC SQL <ROLLBACK | COMMIT>
RELEASE
are performed repeatedly.
636325
Added new SYSDBA, SYSOPER syntax for connect statement
Before 8.0.4, one could use the EMBEDDED SQL CONNECT statement to
connect to user SYS identified by the password CHANGE_ON_INSTALL
with SYSDBA privileges by default as:
EXEC SQL CONNECT :uid IDENTIFIED BY :pwd;
In 8.0.4, the same EMBEDDED SQL CONNECT statement above would
fail,
because it required the user to specify the connection mode. In
8.0.5 Pro*C/C++ the new EMBEDDED SQL CONNECT syntax allows the
user
to specify the connection mode:
EXEC SQL CONNECT :uid [IDENTIFIED BY :pwd]
[AT [:]dbname [USING :hst]]
{ [ALTER AUTHORIZATION :newpwd] | [IN {SYSDBA | SYSOPER}
MODE] }
Restriction:
It is not possible to connect in SYSDBA/SYSOPER mode when using
the AUTO_CONNECT feature.
622811
Memory Leak, when RELEASE_CURSOR=YES option was used
A memory leak occurred when a cursor was closed.
621712
Pro*C produced syntax errors parsing 'extern "C"' constructs
Placing header files inside of a DECLARE SECTION that had
'extern "C"' constructs resulted in syntactic errors. The
problem would occur even if CODE=CPP or PARSE=PARTIAL was
specified because PARSE gets set to FULL when inside of an
explicit DECLARE SECTION. This made trying to build C++
applications using header files generated by the Object
Type Translator problematic because header files produced by
the OTT are required to be included inside of a DECLARE
SECTION when CODE=CPP. Otherwise, important type definitions
would not be parsed by Pro*C. The 'extern "C"' syntax is
usually surrounded by a #ifdef as follows
#ifdef __cplusplus
extern "C" {
#endif
Pro*C defines __cplusplus internally when CODE=CPP so one
simple workaround is to conditionally #undef it using the
ORA_PROC macro as follows
#ifdef ORA_PROC
# undef __cplusplus
#endif
That will cause the 'extern "C"' syntax to never be parsed,
no matter where it occurs (inside of a DECLARE SECTION or
not). ORA_PROC should only be defined during precompilation
so when the generated C code is compiled by the C++ compiler
it should still see the 'extern "C"' code and compile it
without any problems.
607962
VALUES
Incorrect String generation of '', instead of ' for IAF PUT
The code was incorrectly generated, when '' was used in any of
IAF
PUT or TOOLS MESSAGE, or TOOLS SET statements, as part of literal
string.
For example,
EXEC IAF PUT GLOBAL.MSG_TXT VALUES('WHO''S THERE?');
was generating incorrect code with the string as:
"WHO''S THERE?", instead of correct string as "WHO'S THERE?".
588979
Pro*C did not fetch the indicator struct of an object on deref
Pro*C did not obtain the indicator struct of an object on deref.
Workaround was to physically use OCIObjectGetInd with the
environment
provided by SQLEnvGet (see OCI interoperability issue for Pro*C)
588392
SQLLIB leaked memory between allocate and free of context
A Pro*C application which allocated and freed a runtime context
leaked memory for each allocate & free pair of calls.
579807
Pro*C would dump core processing excessively long SQL statements
Pro*C could not correctly process an exceedingly long SQL
statement (ie; one that spanned multiple input lines). A simple
workaround was to break up the SQL statement by introducing line
breaks rather than having the statement stretch across several
continuous lines.
571769
PROC cannot accept #machine in #define
Pro*C could not process the #machine directive properly,
particularly when using it to #define other macros. For example,
#define __mips__ #machine(mips)
The expected value of __mips__ would not be defined appropriately
causing other errors during precompilation. The use of #machine
directives is highly discouraged.
558787
Pro*C could not type resolve complex host variable expressions
Host variable expressions of the form (*x).y or (*x)->y could
not be type resolved by Pro*C. Generally, any parenthesized
host variable expression would not be accepted by Pro*C.
Restriction:
Pro*C will not warn if the host variable expression is not
an lvalue.
Also note that such complex expressions as the ones shown here
must resolve to a scalar or array. Pro*C/C++ cannot handle some
complex host variable expressions that resolve to a struct.
556949
Performance degradation when precompile with MODE=ANSI
ANSI requires a cursor to be CLOSEd before being reOPENed. Thus,
applications precompiled with MODE=ANSI may run slower if cursors
are CLOSEd/reOPENed many times due to the amount of reparsing
associated with each new OPEN. COMMIT closes all OPENed cursors
in such applications.
A new CLOSE_ON_COMMIT option has been added to allow application
developers the ability to choose whether or not to CLOSE cursors
when a COMMIT is executed. Setting CLOSE_ON_COMMIT=NO results in
better performance because cursors will not be closed when a
COMMIT is executed, thus alleviating the need to reOPEN them and
possibly incur extra parsing.
553658 GPF occured on multithreaded application with NLS_CHAR and
NLS_LOCAL
Core dump was seen on NT platform with an application that used
the
precompiler options nls_char and nls_local. In NT multi-threaded
applications the global runtime context did not get correct
nls_char and nls_local information, leading to a core dump.
549812
Core Dump processing multiple file names on the command line
Pro* core dumped when three or more names(e.g., x x x) were given
as
file names. When Pro* processes command line options, it expects
one
input file name and one output file name.
Pro* has been modified
to
allow more than two filenames on command line with the
appropriate
error message.
549142 '%' character dropped when used in a PREPARE or IMMEDIATE
statement
An unquoted text with % character in LIKE comparison inside a
PREPARE or IMMEDIATE statement did not get generated in the
output
file.
For example,
EXEC SQL PREPARE s_pln_count FROM
SELECT COUNT(*) FROM PLN
WHERE plan_type LIKE 'LOAN%';
generated:
sqlstm.stmt="select count(*) from PLN where plan_type like
'LOAN'";
which in turn returned count with value 0.
Correct generated code would be:
sqlstm.stmt="select count(*) from PLN where plan_type like
'LOAN%'";
502066
Core dump when precompiling long .pc filename
On command line, when long (longer than 100 chars) .pc file name
was used with LNAME and LTYPE=LONG option, it corrupted the
memory
and gave core dump. Instead of statically assigning the filename
size, dynamic length is being used.
458658
Problem using # operator in a ## macro definition
Pro*C could not parse a macro definition whose body used a #
operator in a ## operation. For example,
#define strcat(x)
#x ## "foo"
Pro*C would generate syntactic errors. Pro*C will now accept
such syntax, but the stringization and concatenation of the
text will not be performed.
393628
Syntactic errors processing certain complex macro definitions
Pro*C could not handle a macro definition of the following form
#define __P(x) x
#define foo(x) something(x, 10)
extern int foo __P((int))
The trouble was with the use of __P which previously was not
expanded to (int) so that the foo macro could then be recognized
and expanded in the extern declaration.
This also manifested in problems with macros of the form
#define __ARG1(t1, x1) (t1) t1 x1;
and their subsequent use in the creation of subprograms. The
necessary macro expansion of such macros in odd cases would
result in syntactic errors.
316344
Erroneous precompilation when SQL hints are incorrectly placed
Pro*C would not precompile SQL statements that used SQL hints
in illegal places correctly. The resulting generated statement
usually had the text of the hint incorrectly mixed in with the
rest of the statement resulting in runtime errors. SQL hints
use the /*+ .. */ and --+ formats and must appear immediately
following the SELECT, UPDATE, INSERT or DELETE keywords. Any
other placement of a hint comment is erroneous and will be
flagged by the precompiler as a syntactic error. This will
force users who wish to use hints to use them correctly rather
than accept and ignore them lulling the user into thinking that
the hint is having an effect on the execution of the statement.
Bugs Fixed between Release 8.0.3 and Release 8.0.4
==================================================
552084
A failed attempt to logon to the database through Pro*C will
result in a shadow process being left in the server unkilled.
Subsequent failed attempts to logon will result in new shadow
processes being left until either the program itself is
terminated or the server runs out of processes.
546237
Can not connect to the database when using an explicit database
name associated with the username in a connect string. For
example, trying to connect as 'scott@remote' would fail with an
ORA-1017 error.
523931
The WHENEVER NOT FOUND condition was never checked after any of
the various INSERT statements. A PL/SQL trigger on an INSERT
statement that returned NO DATA FOUND would not be trapped by a
WHENEVER NOT FOUND condition for example.
515582
Pro*C would dump core whenever a string literal was used as a
bind variable expression. For example..
EXEC SQL SELECT job INTO :job FROM emp WHERE ename = :"KING";
Use of string literals as bind expressions is ILLEGAL and will
now be flagged as an error by the precompiler.
509647
A core dump would result if the preceeding colon was missing on
an attribute in a Navigational OBJECT SET statement. This did
not occur on the OBJECT GET however.
508256
dump
Processing a DEREF() or REF() in a query would cause Pro*C to
core depending on the platform.
506520
Pro*C would yield a syntactic error when a valid SQL hint was
used in an INSERT statement. Any valid hint would result in such
an error in any form of INSERT statement.
503981 Pro*C can not handle host arrays with dynamic sql method to
execute
a pl/sql block correctly.
286765
When binding host arrays to PL/SQL tables through dynamic SQL,
runtime errors would result.
Host arrays used in a dynamic sql method 2 EXEC SQL EXECUTE
statement may have two different interpretations based on the
presence or absence of the new optional keyword EXECUTE on an
ARRAYLEN statement.
Please refer to Programmer's Guide to the Oracle Pro*C/C++
Precompiler, Release 8.0.4 for more information.
217428
Having two columns in a table of type VARCHAR2(2000) was being
incorrectly considered as two LONG columns which is not allowed.
This prevented applications from being developed using these
sizes for more than one VARCHAR2 column in a table.
Bugs Fixed between Release 2.2.3 and Release 8.0.3
==================================================
472139
Pro*C did not process equivalenced variable when PARSE != FULL
Pro*C would not process a datatype equivalenced variable when
the value of the parse option was not set to FULL. For example
typedef short *sb2ptr;
exec sql begin declare section;
exec sql type sb2ptr is integer(2) reference;
sb2ptr ind;
int x;
exec sql end declare section;
..
exec sql select comm into :x:ind where empno = ..;
The generated code would take the address of ind (&ind) rather
than reference ind directly since it really is a pointer. This
would happen when parse != full only.
471975
Possible read from freed memory using ORACA saved statement text
Precompiler applications that used the ORACA and requested the
statement text could encounter memory-related problems (e.g. core
dumps) when also using dynamic sql. This was particularly likely
to
happen when the host variable used to hold the statement text
pointed
to dynamically allocated memory that was subsequently freed or
when
it was an automatic variable.
A side-effect of this bug fix is
that
sqlgls() no longer returns "old" statement text when called after
a statement that is parsed by the precompiler. For example:
EXEC SQL DECLARE C1 CURSOR FOR SELECT ENAME FROM EMP;
EXEC SQL OPEN C1;
sqlgls() /* Returns "SELECT ENAME FROM EMP" */
EXEC SQL ROLLBACK WORK RELEASE;
sqlgls() /* This returns NO statement text */
471039
Pro*C did not handle SQL hints in DELETE statements correctly
Pro*C would rearrange the DELETE statement in such a way as to
prevent any SQL hint from being used. For example..
exec sql delete /*+ INDEX (emp emp_idx) */ from emp ..
=> "delete from /*+ INDEX (emp emp_idx) */ emp .."
Pro*C would displace the hint which would then result in it
not being used during statement execution.
465932
Pro*C did not allow solitary ' inside a #error directive
Pro*C would treat a single ' as the beginning of a SQL
string literal inside preprocessor directives.
#error This didn't work
Thus, Pro*C would give an error about an unterminated SQL
string when parsing the above #error directive.
443347
Prepare before executing dynamic array gets wrong results
When prepare of an insert statement to be used in a dynamic array
insert and then prepare another statement containing a PL/SQL
block,
at execution it will only insert a single row.
414511
Pro*C did not allow spaces after line continuation in directives
Spaces appearing between a line continuation and the newline
character inside a preprocessor directive were not ignored by
Pro*C. For example
#define foo(a,b) a + \
b
123
1 line continuation
2 space(s)
3 newline (end of line)
This would result in precompile errors during the preprocessing
phase of precompilation. Pro*C now ignores these extra spaces.
408116
Pro*C core dumps if /*+ comment with Multi-Byte characters
Pro*C core dumps when /*+ comments contain Multi-Byte characters
because possibility of Multi-Byte characters wasn't considered.
406516
Long PCC-F-02135 messages on command line options get chopped off
If values of help options, such as the INCLUDE files, are very
long
and the user asks to see a help message on such an option, only
part
of the value would be shown, and in some cases a segfault would
occur.
402136
ORA-1459 When inserting a NULL with a VARCHAR variable
The message ORA-1459:invalid length for variable character string
is returned when varchar pointers which point to zero-length
strings are inserted into the database.
400907
Option values longer than 80 characters cause precompiler to hang
When an option list is used, where the combined length of the
list
values exceeds 80 characters, the precompiler will hang.
397811
Array size mismatch in Array DML with 'AT :database' clause
Pro*C would give an array size mismatch error on a DML statement
with host arrays (of equal dimension) when an 'AT :database'
clause was present. Note that the DBNAME in the AT clause was
itself a scalar host variable which was causing the mismatch.
397223
Cannot refer to a specific element of an undimensioned array
The problem was that when a specific element of an Undimensioned
array was used in an EXEC SQL statement as a Host variable, it
gave
a Precompiler Error. Precompiler Error was generated to FIX the
coredump of 215929. With this FIX, it removes the Core dump, and
proceeds for correct precompilation and execution, without any
precompile.
382795
Pro*C can't parse "#define ident 'LOTTO'" directive
When user uses #define ident B, Pro*C flagged an error because of
ident, as a keyword was not allowed for #define. (To make a note
that
ident is used as a keyword on some platforms). So, the gramamr
rule
was changed to accomodate the use of "ident" same as other
keywords
like if, ifdef, etc.
371255
Seg Fault when pointer is invalid but indicator is null
When a bind variable pointer is invalid and the associated
indicator is set to -1, an access violation occurs.
366775
Core dump precompiling with THREADS=YES - Temp files not deleted
Although, it's user's responsibility to write code needed for
threads=yes to work, it should NOT core dump. With this FIX, it
generates the semantic error message, and then tmp files are
deleted.
For example, the following error message will be generated for
the
testcase supplied with this bug:
(1) PCC-F-02390, No EXEC SQL CONTEXT USE statement encountered
359035 NLS: Column position is not correct when comment line is
generated
When NLS char exist in a stream of chars, then due to multibyte
column count needed to be corrected. For example, if there are
45 chars in a stream, out of which 2 are NLS (multibyte), then
in reality there are only 43 chars. If 45 is used, then it will
fetch next 2 bytes, which might happen to be the beginning of
comment /*. This will mess up the whole comment structure. So
the number of correct char. counts is calculated with this fix.
345010
Pro*C could not handle use of the ANSI token merging operator
Using the merging operator '##' would cause Pro*C to generate
spurious syntactic error messages. The syntax is now accepted
but the merging is not done. Pro*C will accept the use of the
operator but will not support the functionality.
344346
Precompiler help screen loops infinitely for some NLS languages
When requesting the help screen, precompiler would loop
infinitely
for certain NLS languages in which the description of the command
line option was excessively long, without intervening spaces so
much
so that it could't fit on a single line without being broken up
into
multiple lines.
268198
Pro*C did not allow split of EXEC SQL BEGIN/END DECLARE SECTION
Pro*C required that EXEC SQL BEGIN/END DECLARE SECTION be
written all on one line with the possibility of splitting it
across multiple lines. Syntactic errors would result otherwise.
479063
Spurious runtime errors when using arrays of LOB types
The precompiler produced incorrect code when processing certain
array declarations of LOB types, particularly when they appeared
in
a function parameter list. For example, the following statement
was not precompiled correctly:
void BlobFunc(multi_blob)
OCIBlobLocator *multi_blob[];
475284
Pro*C dumped core after generating certain error messages
Pro*C would dump core after finding certain errors related to
the use of bind variables declared to be of some new Objects
related types (ie; OCINumber). This would also happen due to
the fact that an Objects program was being precompiled without
specifying an INTYPE file.
469671
Pro*C dumped core when processing long lines of Multibyte text
For excessively long lines of input having a lot of Multibyte
text, Pro*C would terminate abnormally with a core dump.
464714
The FIPS report showed all violations occured at line 0 (zero)
The FIPS report generated by Pro*C would indicate that all
violations occured at line 0 (zero) rather than the actual
source line in the program where the violation really occured.
463066
Pro*C did not allow C expressions in Equivalence statements
Pro*C did not allow complex precompile time evaluable constant
expressions to be used in datatype equivalence statements.
#define LENGTH 10
char x[LENGTH+1];
EXEC SQL VAR x IS STRING(LENGTH + 1);
Pro*C now accepts any constant expression that can be
evaluated to a numeric value at precompile time in any SQL
datatype length specification for VAR/TYPE statements.
461907
length
Pro*C did not give an error for a LONG VARCHAR with missing
The LONG VARCHAR datatype requires a length. Pro*C, however,
would accept a LONG VARCHAR without a length which would result
in
a runtime error.
EXEC SQL VAR foo IS LONG VARCHAR;
This is illegal.
454733
A syntactic error message is now generated.
Pro*C/C++ didn't accept WITH clauses in any subquery
New with Oracle8 were the addition of WITH clauses in subqueries.
Pro*C didn't allow WITH clauses. Instead, syntactic errors would
result. The following was not accepted for example..
EXEC SQL INSERT INTO (SELECT ename, deptno FROM emp
WHERE deptno > 10 with check option)
VALUES ('Taylor', 20);
The 'with read only' clause would also not be accepted.
workaround was to use Dynamic SQL instead.
454727
The only
Pro*C did not accept the PARTITION clause on a table name
Pro*C would reject syntactically the use of the PARTITION
clause on a table name in any DML statement. For example,
EXEC SQL DELETE FROM sales PARTITION (nov96) WHERE ..
the only workaround was to use Dynamic SQL.
453328
Pro*C could not handle userid option if SQLCHECK != FULL
Pro*C would not allow the use of the userid option if the
SQLCHECK option was not set to FULL.
434744
Command-line options were not added to list file for LTYPE=LONG
When the ltype command-line option is set to long, the current
command-line option values should appear in the listing file.
Also, the formfeed character should appear between pages, but
not as the first character in the list file.
429924
Pro*C could not handle use of '&' in whenever statements
Pro*C would not allow use of the '&' operator in whenever
statements. For example..
EXEC SQL WHENEVER SQLERROR DO sql_error(&x);
An unintelligable error would result. Pro*C now accepts
this as a form of complex expression which it can now
handle better.
428633
Pro*C did not allow unary expressions in a WHENEVER statement
Pro*C would not allow a unary expression in a WHENEVER
statement. For example..
EXEC SQL WHENEVER SQLERROR DO sql_error(-1);
Now Pro*C will accept any unary expression. Binary expressions
are NOT supported in a WHENEVER statement currently, however.
426826
Pro*C dumped core if when allocating an undefined variable
Pro*C would dump core if an allocate of an undefined variable
was attempted. For example..
EXEC SQL ALLOCATE :undefined;
Now a useful error is generated stating that both the variable
is undefined and that a type error occured on the allocate.
406664
Pro*C would not include a file whose name was a macro
Pro*C would only allow files defined by a macro to be
#included if code=ansi_c or cpp. Some kr_c compilers
allow this but Pro*C would yield syntactic errors.
#define HEADER "file.h"
#include HEADER
This worked when CODE=ANSI_C or CPP, but not KR_C. No
real workaround since use of ANSI_C generated code that
would not compile with a KR_C compiler.
399274
Pro*C sometimes switches the order of START WITH .. CONNECT BY
Originally, Pro*C would always generate 'START WITH' followed
'CONNECT BY' even if the 'CONNECT BY' appeared first. This
would cause problems if the statement was a prepared statement
subsequentally used with an explicit cursor. The resulting
'OPEN USING <bind variable list>' would hence sometimes result
in the bind variables being in the wrong order because the
statement was generated in the opposite order. This would cause
runtime type mismatch errors during execution of the program.
364746
Pro*C would not allow a <table>.* reference without a C++ error
Pro*C would give an error about using C++ punctuation even with
a legal <table>.* reference in a SQL statement. For example
EXEC SQL SELECT emp.* INTO :emp_struct FROM emp;
Workaround was to remove the 'emp.' and just do a 'select *'.
Note that the error only occured when precompiling with CODE=CPP.
SECTION 5: RESTRICTIONS IN PRO*C/C++ 8.1.6
----------------------------------------------------------------------------------1. #include vs EXEC SQL INCLUDE
(Bug 450572)
Programs that include the Oracle header files such as sqlca.h or
sqlda.h
using BOTH a #include and an explicit EXEC SQL INCLUDE will not
precompile
correctly resulting in generated code that does not compile. The
simplest
workaround is to just use a #include wherever possible, avoiding the
use
of the older EXEC SQL INCLUDE syntax altogether.
2. New Datatypes
Below is a table which lists the known restrictions and bugs in the
new
functionality introduced in Pro*C/C++ Versions between 8.0.3 and
8.1.6.
New C types
PRO*C/C++
SUPPORT IN
EMBEDDED SQL
PRO*C/C++
PRO*C/C++
SUPPORT FOR
SUPPORT IN
BULK OPERATIONS *1
EMBEDDED
In Oracle8
PLSQL *2
-------------------------------------------------------------------------OCINumber
| yes
| no
| yes
OCIString
| yes *3
| no
| no
OCIRaw
| yes
| no
| yes
OCIDate
| yes
| no
| no
OCIRef
*4 | yes
| yes
| no
OCIBlobLocator
| yes
| yes
| yes
OCIClobLocator
| yes *5
| yes *5
| yes *5
ADT's
*6 | yes
| yes
| yes *7, *8
Nested Tables
| yes
| yes
| yes
VARRAYS
| yes
| yes
| yes
-------------------------------------------------------------------------*1) This column refers to Pro*C/C++ support for multi-row (bulk)
embedded
SQL operations with bind variables that are arrays of the given
host
type.
*2) Arrays of new C types are not supported in PL/SQL blocks embedded
within
Pro*C/C++.
*3) Host variables of type OCIString are supported only within ADTs.
If a
character attribute of an object type is mapped by OTT to an
OCIString
field in a C struct, then it can be used within Pro*C/C++ only in
operations that manipulate the object as a whole.
Use of such an OCIString field individually, as a stand-alone bind
variable (e.g., to bind to a column in a relational table) is
currently
not supported.
*4) OCIRef host variables (representing REFs in the Oracle8 database)
are
supported within embedded SQL and in the Pro*C/C++ mode
SQLCHECK=SYNTAX.
However, OCIRef variables cannot be used in embedded PL/SQL
blocks, or
with the Pro*C/C++ command line option SQLCHECK=FULL (or
equivalently,
SEMANTICS).
A work-around is to always use SQLCHECK=SYNTAX for Pro*C/C++
program
modules that contain OCIRef variables. This may require a
Pro*C/C++
application program to be modularized into multiple .pc files such
that
a .pc file with a OCIRef variable does not contain any embedded
PL/SQL
blocks (which are required to be precompiled with the option
SQLCHECK=FULL).
*5) National Character LOBs are also supported in 8.1.6 except as
attributes of an Object Type.
*6) User-defined named data types are not supported in Oracle Dynamic
SQL
Method 4. They are supported using the new ANSI Dynamic SQL
Interface.
*7) Selecting whole ADT instances from typed tables using the VALUE()
function on a table alias is not supported in embedded PL/SQL, or
with
the Pro*C/C++ command line option SQLCHECK=FULL (or SEMANTICS).
*8) ADT attributes of type LOB cannot be manipulated in embedded
PL/SQL.
A work-around is to use OCI routines or the Embedded SQL LOB
Interface
to manipulate LOB attributes embedded in ADTs.
3. Type Equivalencing Operations
Pro*C/C++ has never expanded macros used as type names in an EXEC SQL
TYPE directive. For example, the following would never have been
supported by any version of Pro*C/C++
#define text char
EXEC SQL TYPE text IS STRING(..);
The 'text' macro has never been expanded. This caveat of Pro*C/C++ is
well documented in the manual. It is mentioned here because in
earlier
versions of Oracle releases, the 'text' word was defined using a C
typedef which would have allowed the above EXEC SQL TYPE statement to
work.
In the event that an Oracle bundled release changes the definition of
'text' from a typedef to a macro, any SQL directives such as the one
above would thus fail to precompile.
MISCELLANEOUS ISSUES
--------------------------------------Support for Object Navigation
----------------------------Another alternative for the application programmer is to use the
Navigational
(ORI) routines within or in conjunction with a Pro*C/C++ program, after
connecting to the database(s) in Pro*C/C++. As described in Section 1
above,
an 8.1 OCI environment handle and the service context handle for a given
database connection may be obtained using the new library functions
provided
by SQLLIB.
Multi-Row Bulk (Array) Operations in Embedded SQL
------------------------------------------------Multi-row array operations for objects (ADTs) require that the host
variable
arrays be *pointers* to the OTT-generated C structs, for both input and
output.
Likewise, multi-row array operations on REF variables (of C type OCIRef)
and
LOB locators (of C types OCIBlobLocator, OCIClobLocator) require that the
host
arrays be pointers of the appropriate C type. For example, a valid
declaration of such arrays in a Pro*C/C++ program appears as:
OCIRef
OCIBlobLocator
OCIClobLocator
*ref_array[..];
*blob_array[..];
*clob_array[..];
The PARSE command line option and its value
------------------------------------------The default value of the PARSE option is set to FULL so that Pro*C/C++
will
fully preprocess and parse the entire program. This is required
especially
when using the Object features provided by Oracle 8.1.6.
Pro*C/C++ Configuration File
---------------------------The Pro*C/C++ configuration file precomp/admin/pcscfg.cfg needs to be
updated
with the appropriate path for $ORACLE_HOME. For example, in the
following
pcscfg.cfg file, change the string "/vobs" by the actual path for the
value
of $ORACLE_HOME. Note that you may only use absolute or relative paths
in the
config file which means that no environment variables will be accepted
there.
sys_include=(/usr/include)
include=(/vobs/precomp/public)
include=/vobs/precomp/hdrs
include=/vobs/tpcc2x_2/src
include=/vobs/precomp/include
include=/vobs/oracore/include
include=/vobs/oracore/public
include=/vobs/rdbms/include
include=/vobs/rdbms/public
include=/vobs/rdbms/demo
include=/vobs/nlsrtl/include
include=/vobs/nlsrtl/public
include=/vobs/network_src/include
include=/vobs/network_src/public
include=/vobs/network/include
include=/vobs/network/public
include=/vobs/plsql/public
ltype=short
Setting the LTYPE=SHORT option value will cause .lis files to be
generated
using the verbose form rather than the expository form in which the
entire
program is listed.