readme_proc.txt

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

        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  Processing a DEREF() or REF() in a query would cause Pro*C to dump
        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