readme_proc.txt

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

	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  Pro*C did not give an error for a LONG VARCHAR with missing length

        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.  A syntactic error message is now generated.

454733  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.  The only
        workaround was to use Dynamic SQL instead.

454727  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++           PRO*C/C++          PRO*C/C++
		       SUPPORT IN          SUPPORT FOR         SUPPORT IN
   In Oracle8         EMBEDDED SQL     BULK OPERATIONS *1   EMBEDDED 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