readme_proc.txt

Debian中文参考手册,系统介绍了Debian系统

        "sizeof" in the type of any host variables.

1175132 Unnecessary parsing for INSERT caused performance degradation.

	When INSERT statement caused an ORA-0001 error, it triggered 
	reparsing of INSERT statement everytime, causing performance
	degradation.  Reparsing was not done only for ORA-1403, ORA-1405 
	and ORA-1406.  With the fix, reparsing will never be done unless 
	parse errors occurs.

897697  Pro*C/C++ can not handle translate function with USING clause.

        When "USING" clause was used in a translate function, Pro*C/C++
        generated PCC-S-02201 error at precompile time.

746347  Dynamic sql method-4 generated wrong sqlerrd[4] value. 

	Dynamic sql method-4 generated wrong sqlerrd[4] value 
	to point to erroneous column number.  With the fix, correct 
	value is getting assigned to sqlerrd[4]. 

Bugs Fixed between Release 8.1.6 and 8.1.7
==========================================


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 [e-mail]@q1;

        would result in syntactic errors on the use of the '@' signifying
        the connection qualifier.

693939  Blank padded character types were not padded with ANSI dynamic SQL

        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  Pro*C/C++ sees host field length as 0 if length is specified in HEX

        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.  A
        workaround was to use the /*+ .. */ hint format as an alternative.

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  SQLLIB returned 1012 (not connected) even when connection was valid

        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  Incorrect String generation of '', instead of ' for IAF PUT VALUES

        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