readme.doc

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

        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 
       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          *ref_array[..];
      OCIBlobLocator  *blob_array[..]; 
      OCIClobLocator  *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.