readme.doc

orale培训教材包括了所有的sql说明和实例

        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

        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"