
New Features
This appendix describes the new features offered in the Pro*C/C++ Precompiler, Release 2.2. Each new feature is described briefly, and a pointer to the more complete description in the chapters is provided.
Fetching NULLs without Using Indicator Variables
With releases 2.0 and 2.1 of the Pro*C/C++ Precompiler, source files that FETCH data into host variables without associated indicator variables return an ORA-01405 message at runtime if a NULL is returned to the host variable. With release 2.2, when you specify MODE=ORACLE and DBMS=V7, you can disable the ORA-01405 message by also specifying UNSAFE_NULL=YES.
When developing applications for the Oracle7 Server, the preferred practice is to include indicator variables for any host variable that might have a NULL returned to it. When migrating applications from Oracle Version 6 to Oracle7, however, the UNSAFE_NULL option can significantly ease the process.
For more information, see "UNSAFE_NULL"
and "Using Indicator Variables" Chapter 1 of your host-language supplement.
Using DBMS=V6
Applications precompiled with DBMS=V6 maintain full compatibility with Oracle Version 6. When upgrading to Oracle7, if you precompile with DBMS=V6 specified, your applications will be unaffected by the ORA-01405 messages.
Using DBMS=V7 and MODE=ORACLE
Applications precompiled with MODE=ORACLE and DBMS=V7 return the ORA-01405 error at runtime if a NULL is returned to a host variable when there is no associated indicator variable. When upgrading to Oracle7 with these options specified, you will need to migrate your applications in one of two ways:
- modify your source code to include the necessary indicator variables
- specify UNSAFE_NULL=YES on the command line
If you are upgrading to Oracle7 and use DBMS=V7 when precompiling, or if you intend to use new Oracle7 features that are different from Oracle Version 6, in most instances, the change requires minimal modification to your source files. However, if your application may FETCH null values into host variables without associated indicator variables, specify UNSAFE_NULL=YES to disable the ORA-01405 message and avoid adding the relevant indicator variables to your source files.
Related Error Messages
For information about precompile time messages associated with the UNSAFE_NULL option, see Oracle7 Server Messages..
Support for Developing Multi-threaded Applications
The Pro*C/C++ Precompiler now supports development of multi-threaded Oracle7 Server applications (on those platforms that support multi-threaded applications) using the following:
- a command-line option to generate thread-safe code
- embedded SQL statements and directives to support multi-threading
- thread-safe SQLLIB and other client-side Oracle libraries
For an introduction to threads and how to use these features, see "Developing Multi-threaded Applications"
.
THREADS Option
With THREADS=YES specified on the command line, the Pro*C/C++ Precompiler ensures that the generated code is thread-safe, given that you follow the guidelines described in "Programming Considerations"
. With THREADS=YES specified, Pro*C/C++ verifies that all SQL statements execute within the scope of a user-defined runtime context.
Embedded SQL Statements and Directives
To support multi-threaded development with executable embedded SQL statements, the Pro*C/C++ Precompiler use the EXEC SQL commands and directives listed in Table A - 1 and are further described
.
EXEC SQL Command
| Type
| Purpose
|
CONTEXT ALLOCATE
| SQL Extension
| To allocate memory for a SQLLIB runtime context.
|
CONTEXT FREE
| SQL Extension
| To free memory for a SQLLIB runtime context.
|
CONTEXT USE
| Directive
| To specify which SQLLIB runtime context to use.
|
ENABLE THREADS
| SQL Extension
| To initialize a process that supports multiple threads.
|
Table A - 1. Precompiler Directives and Embedded SQL Commands
Thread-safe SQLLIB Public Functions
For developers of multi-threaded applications, the Pro*C/C++ Precompiler release 2.2 is accompanied by a thread-safe version of the SQLLIB runtime library. All of the public functions are included as are their thread-safe counterparts. Thread-safe public functions are named similarly to the other public functions but are suffixed with a t. For more information about the thread-safe SQLLIB functions, see "Thread-safe SQLLIB Public Functions"
.