|
Oracle® Databaseプラットフォーム共通日本語README 10g リリース1（10.1） |
|
|
|
原典情報: $ORACLE_HOME/precomp/doc/proc/readme.doc
目次
2 新機能3 Pro*C/C++リリース10.1.0.2.0の既知の不具合
4 このリリースで修正された不具合7 『Pro*C/C++ Precompiler プログラマーズ・ガイド』の補足事項
特に、V6互換性フラグでは、Oracle7でOracle6の動作の次の側面がエミュレートされていました。
Oracle8では、V6互換性フラグのサポート中止に伴い、これらの動作のサポートがすべて中止となります。
o すべてのホスト変数は、PL/SQLブロックの実行前に初期化する必要があります。これは、PL/SQLからみた変数の基盤となるモード（IN、IN/OUT、OUT）に関係なく該当します。この要件は、埋込みPL/SQLの実行時パフォーマンスを改善することを意図したものでした。
o OCIの相互運用性関数sqlcda()およびsqlcur()（SQLCDAFromResultSetCursorおよびSQLCDAToResultSetCursor）を使用するアプリケーションでは、埋込みSQLを介して接続を確立した直後にsqllda()またはsqlld2()（SQLLDAGetCurrentまたはSQLLDAGetNamed）をコールする必要があります。次に例を示します。
sql_cursor curvar;
Lda_Def lda;
Cda_Def cda;
EXEC SQL CONNECT :uid IDENTIFIED BY :pwd;
/* This function must be executed immediately after connecting */
SQLLDAGetCurrent(&lda);
/* Continue with logic to allocate, open a fetch using curvar */
EXEC SQL ALLOCATE :curvar;
EXEC SQL EXECUTE
BEGIN
open :curvar for select ename from emp order by empno;
END;
END-EXEC;
EXEC SQL FETCH :curvar INTO :name;
sqlcda(&cda, (dvoid *)&curvar, &code);
ofetch(&cda);
これにより、接続がバージョン7モードになるため、プリコンパイラのカーソル変数とバージョン7のCda_Defの間の変換が可能になります。接続がバージョン7モードの場合は、ユニバーサルROWID（OCIRowid *）を使用できないことに注意してください。
暗黙的にバージョン7モードの処理を示すsqlldaのコールは、暗黙的にバージョン8の処理を示すSQLSvcCtxGetや他のコールと混在できないことに注意してください。sqlldaのサポートは、下位互換性のためにのみ提供されます。
o ROWID
ROWID列に対するDESCRIBE (EXEC SQL DESCRIBE SELECT LIST . . .)は、SQLT_RID型ではなくSQLT_RDD型を戻します。
通常、プログラマはすべての新規開発にユニバーサルROWID（OCIRowid *型）を使用する必要があります。これにより、アプリケーション・コードを変更せずに、基礎となる表をヒープ表から索引構成表に移行できます。
o NULLのフェッチ時に標識変数が存在する場合、対応するホスト変数の内容は変更されません。標識変数の値をチェックして、NULL/NOT NULLステータスを判断する必要があります。
o 対応する標識変数のないホスト変数にNULLが選択またはフェッチされる場合、問合せ処理は停止しません。以降の各行も引き続きユーザー・ホスト変数に取り出され、処理済行数には選択またはフェッチされた行の総数が反映されます。どの行にNULL値が含まれているかの判別には使用できません。
将来は、実装間で生成コードの互換性をサポートするために、32ビット・バイナリと64ビット・バイナリの両方をサポートするポートでは、1バージョン、つまり64ビット・バージョンのsqlca.hのみが提供される可能性があります。
a. パスワードの期限切れ
このリリースのPro*C/C++では、埋込みSQL CONNECT文への構文拡張を介して、アプリケーションで実行時にユーザーのパスワードを変更できます。b. 構造体の配列
構造体の配列と構造体の配列へのポインタが、埋込みSQLのホスト変数および標識変数としてサポートされるようになりました。c. ラージ・オブジェクト（LOB）とBFILEのサポート
ホスト変数を特定のLOBロケータ型として宣言することで、BLOB、CLOB、NCLOBおよびBFILEを操作できます。これらのホスト変数を埋込みSQLで使用し、サーバー上でLOBを参照できます。d. NCHARデータのサポート
NCHARデータがカーネルにより完全にサポートされるようになりました。以前のリリースのプリコンパイラでは、このデータ型はNLS_LOCALオプションを使用してサポートされていました。新規アプリケーションの場合は、データベース・サポートに依存し、それに従ってプリコンパイル時にNLS_LOCAL=NOに設定することをお薦めします。e. ユーザー・コール可能なSQLLIB関数
既存のユーザー・コール可能なSQLLIB関数には、より説明的な長い名前が使用されていました。互換性を維持するため、従来の名前も引き続き使用できます。すべての新規アプリケーションには、新規の名前を使用することをお薦めします。f. ユーザー設定可能なランタイム・コンテキスト・オプション
ランタイム・コンテキストにオプションがあり、作成して割り当てるとデフォルト値に設定されます。特定のランタイム・コンテキスト値を設定するための汎用メカニズムが導入されています。ただし、現在サポートされているオプションは少数です。g. SYSDBAおよびSYSOPER接続モードのサポート
以前のリリースのOracleでは、次のように指定してSYSDBA権限で接続できました。EXEC SQL CONNECT :<uid> IDENTIFIED BY :<pwd> ;
この場合<uid>はSYSを含むホスト変数、<pwd>はCHANGE_ON_INSTALLを含むホスト変数です。デフォルトでは、前述の構文ではSYSDBA権限を使用できなくなったため、Pro*C/C++では埋込みCONNECT文のオプションのIN MODE句がサポートされるようになり、この句にSYSDBAまたはSYSOPERモードを指定できます。
h. 新規のWHENEVERアクションDO CONTINUE
DO CONTINUEアクションの動作は、DO BREAKに似ています。後者の場合は、明示的なBREAK文が発行されます。DO CONTINUEアクションの場合は、CONTINUE文が生成されます。これは、単にプログラムが続行されるCONTINUEアクションとは異なります。a. 埋込みSQL LOBインタフェース
簡単で使いやすい埋込みSQL LOBインタフェースが用意されており、アプリケーション開発者にとってはLOBのサポートが拡張されます。これは、Oracle OCI APIやPL/SQL DBMS_LOBパッケージの場合と同じ機能のサポートがLOBに関して提供されることを意味します。
b. ANSIの動的SQLインタフェース
Pro*C/C++には、ANSI規格から導出された動的SQLの新規実装が用意されています。ANSIの動的SQLインタフェースは、Oracleの動的SQLメソッド4のインタフェースよりも強化されています。また、このインタフェースでは、オブジェクト、構造体の配列、カーソル変数およびLOBなど、すべてのOracleのタイプがサポートされます。
c. DML RETURN句
Pro*C/C++では、INSERT、UPDATEおよびDELETEの各埋込みSQL DML文でDML RETURN句の使用がサポートされるようになりました。
d. ユニバーサルROWIDのサポート
このリリースのPro*C/C++には、物理ROWID（ヒープ表に関連付けられたROWID）と論理ROWID（索引構成表に関連付けられたROWID）の両方と互換性のあるROWID記述子をALLOCATEおよびFREEにするメカニズムが用意されています。ROWID記述子はOCIRowid *として宣言します。この種の記述子は、埋込みSQL文でホスト変数として使用できます。すべての新規開発では、ROWID記述子を使用することをお薦めします。e. ランタイム・コンテキストのサポート拡張
埋込みCONTEXT USE文の拡張により、開発者は特定のランタイム・コンテキストを指定するか、かわりにデフォルトのグローバルなSQLLIBランタイム・コンテキストに設定できるようになりました。f. 外部プロシージャのサポート
Pro*C/C++で記述された外部プロシージャをPL/SQLからコールできるようになりました。REGISTER CONNECT埋込みSQL文が導入されています。この新しい文を外部プロシージャでCONNECT文のかわりに使用し、グローバルなSQLLIBランタイム・コンテキストに対して現行の名前のない接続を定義します。g. プリフェッチのサポート
Oracleでは、問合せの実行時に行数のプリフェッチ指定がサポートされます。これにより、以降に行がフェッチされるときにサーバーのラウンドトリップが不要になり、パフォーマンスが向上します。Pro*C/C++でプリフェッチを使用可能にするには、新規のコマンドライン・オプションPREFETCH = 0 .. 65535を使用します。PREFETCH値は、問合せの実行時にプリフェッチされる行数を示します（0はプリフェッチが使用禁止であることを意味します）。このオプションは、構成ファイル、コマンドラインまたはインラインで使用できます。h. Javaストアド・プロシージャのコール
Pro*C/C++リリース8.1.4には、新規の埋込みSQL CALL文が導入されています。この文を使用すると、アプリケーション開発者は埋込みPL/SQL無名ブロックを使用せずにJava（およびPL/SQL）ストアド・プロシージャを直接コールできます。i. プリコンパイル済ヘッダー機能
リリース8.1.5以上のPro*C/C++では、ヘッダー・ファイルをプリコンパイルし、そのプリコンパイル内容を特殊なバイナリ・ファイルに格納できます。このファイルは、通常のPro*C/C++プログラムまたは他のヘッダー・ファイルのプリコンパイル時に#includeディレクティブを介してインクルードするときに、実際にヘッダー・ファイルをプリコンパイルするかわりにインスタンス化できます。新規のプリコンパイル済ヘッダー・メカニズムを使用可能にし、バイナリ・ファイルの生成時と検索時に使用するファイル拡張子を指定できるように、新規コマンドライン・オプション（header）が用意されています。a. 完全に統合されたデバッグ機能
リリース8.1.6以上では、LINES={YES|NO}オプションの動作が変更されています。現在は、LINES=YESを指定すると、出力プログラムでは生成コードの各行の後に#lineプリプロセッサ・ディレクティブが生成されます。これにより、GDBやMicrosoft Visual Studio for C++のようなIDEなどのデバッガを使用する開発者は、生成されたコードをステップ実行するかわりに、Pro*C/C++のソース・プログラムを表示してアプリケーション・プログラムをデバッグできます。a. Unicodeのサポート
Pro*C/C++ 8iには、UCS2/UTF16エンコーディングを使用するアプリケーション向けにUnicode変数（UTF16）が導入されています。ただし、変数をバインドできるのはデータベースのCHAR型のみで、バインド/定義バッファは暗黙的にサーバー側データベース・キャラクタ・セットに変換されます。Oracle9iのデータベースの「信頼性の高いUnicodeデータ型サポート」を使用すると、Pro*C/C++のUTF16データをCHAR列とNCHAR列の両方にバインドできます。
Pro*C/C++ 9iでは、ターゲット列がNCHARの場合のデータ消失の可能性を回避するために、NCHARがUnicode（UTF16）データのデフォルトのキャラクタ・セット・フォームとして使用されます。CHARと併用すると、わずかながらパフォーマンスに影響すると予想されます。
Pro*C/C++ 9iには、パフォーマンスと下位互換性のためにUnicode（UTF16）変数と併用できるように、新規のプリコンパイラ・オプションUTF16_CHARSETが導入されます。
UTF16_CHARSET=NCHAR_CHARSET（デフォルト）を指定すると、Unicode（UTF16）のバインド/定義バッファはサーバー側の各国対応キャラクタ・セットに従って変換されます。ターゲット列がCHARの場合は、パフォーマンスに影響する可能性があります。
UTF16_CHARSET=DB_CHARSETを指定すると、Unicode（UTF16）のバインド/定義バッファはサーバー側のデータベース・キャラクタ・セットに従って変換されます。ターゲット列がNCHARの場合は、データ消失の可能性があることに注意する必要があります。
9i以上では、NLS_NCHAR環境変数を指定しないと、NCHARデータには定義済のキャラクタ・セットまたはNLS_LANGにより間接的に定義されているキャラクタ・セットが使用されます。詳細は、『Oracle Application Server 10g グローバリゼーション・ガイド』を参照してください。
b. 日時
リリース9.0.1では、Pro*Cの日時サポートがすべての日時機能に拡張されます。
c. バージョン8のOCIのXAサポート
リリース9.0.1では、XAとOracle 8のOCIとの相互運用性が標準となります。sqlldaとhstdefsに対するサポートは、このリリースで廃止になります。
リリース9.2.0のPro*C/C++では、スクロール可能カーソルを使用してデータをランダムにフェッチできます。
b. Pro*C/C++での接続プーリングのサポート
リリース9.2.0のPro*C/C++では、接続プール・オプションを使用してPro*C/C++アプリケーションのパフォーマンスを最適化できます。デフォルトでは、接続プール・オプションは使用禁止になっています。
c. Pro*C/C++デモを作成するための新規Makeファイル
リリース9.2.0のPro*C/C++をインストールすると、demo_proc.mk Makeファイルとともに2つ以上のMakeファイル、viz.、demo_proc32.mkおよびdemo_proc64.mkが作成されます。この新規Makeファイルは、追加の32/64ビット・サポートが必要な場合に使用します。a. システム固有のfloat/doubleのサポート
リリース10.1.0.2.0のPro*C/C++では、新規データ型であるシステム固有のfloat型とdouble型がサポートされます。この2つのデータ型は、単精度と倍精度の浮動小数点値を表します。どちらもシステム固有の方法、つまり、ホスト・システムの浮動小数点書式で表されます。次の表に、リリース9.2.0の『Pro*C/C++ Precompiler プログラマーズ・ガイド』の表15-1の補足事項を示します。
| 内部Oracle データ型 |
コード |
|---|---|
BINARY_FLOAT |
100 |
BINARY_DOUBLE |
101 |
次の表に、リリース9.2.0の『Pro*C/C++ Precompiler プログラマーズ・ガイド』の表15-2の補足事項を示します。
| 外部データ型 | コード | Cデータ型 |
|---|---|---|
SQLT_BFLOAT |
21 |
float |
SQLT_BDOUBLE |
22 |
double |
a. オブジェクト型のサポート
Pro*C/C++では、埋込みSQLおよびPL/SQL文を介してオブジェクト型のホスト変数の操作がサポートされます。OTT（Object Type Translator）を実行して、Oracle8データベースに定義されている特定の型のC構造体のtypedefを生成し、Pro*C/C++アプリケーション・プログラム内でこれらの型（または型へのポインタ）の変数を宣言して、Oracle8データベース内のオブジェクト・インスタンスに対応付ける必要があります。b. OTTにより生成される型ファイルの使用
コマンドラインで追加のPro*C/C++入力ファイルであるINTYPEファイルを指定し、オブジェクト型に関して必要な情報をプリコンパイラに提供します。このファイルは、Oracle8データベースのオブジェクト型をC構造体のtypedefに変換するときに、OTTにより生成されます。c. ナビゲーション操作のサポート
オブジェクトの作成、オブジェクト参照の操作、オブジェクト属性の設定および取得の各操作を提供するのみでなく、オブジェクト・キャッシュ内のオブジェクトの確保と確保解除を制御するナビゲーショナル・アクセス用インタフェースが提供されています。注意: REFは、それが戻されるすべてのインスタンス内で割り当てる必要があります。特に、RETURNING REFを使用するEXEC SQL OBJECT CREATEのコールでは、RETURNING REF INTOに続くホスト変数に（EXEC SQL ALLOCATE :hvを介して）割当済のREFを含める必要があります。
a. リリース8.0.3では、オブジェクト型のLOB属性およびCollection属性の取得および設定機能を組み込むためにナビゲーショナル・アクセス用インタフェースが導入されましたが、リリース8.1.5ではこのインタフェースが拡張されています。EXEC SQL OBJECT DEREF文のオプションのFOR UPDATE句も、オプションのNOWAITを使用して拡張されています。
b. コレクションのサポートの拡張
コレクションの個々の要素にアクセスし、変更および更新できるように、新しい埋込みSQLインタフェースが用意されています。このインタフェースは、OCI APIで現在提供されている便利で使いやすい埋込みSQLスタイルと同様の機能サポートを、コレクションに対して提供することを意図しています。
a. 継承
Oracle9iのオブジェクト型サポートの一部として、プリコンパイラのオブジェクト・サポートに継承のサポートが組み込まれました。
Pro*C/C++リリース9iでは、次のSQL演算子を使用してオブジェクト型の継承がサポートされます。
* IS OF typeb. マルチレベル・コレクション
リリース9iのコレクション・オブジェクト型サポートが拡張され、複数レベルでネストした表およびVARRAYを含むコレクションが許可されるようになりました。a. 新規のOCI相互運用性機能
リリース8.1.6のPro*C/C++プログラムとリリース8.1のOCIとの相互運用をサポートするために、新規のライブラリ・ルーチンSQLEnvGet()およびSQLSvcCtxGet()が導入されています。前述のルーチンを使用すると、Pro*C/C++で確立されたデータベース接続について、リリース8.1のOCI環境ハンドルとリリース8.1のOCIのサービス・コンテキスト・ハンドルを取得できます。リリース8.0.3〜8.1.6の間でPro*C/C++に導入されたほとんどの新機能のデモ・プログラムは、関連SQLスクリプトとともにPro*C/C++のdemoディレクトリにあります。次に例を示します。
前述のプログラムのコードは$ORACLE_HOME/precomp/demo/procディレクトリにあり、関連SQLスクリプトは$ORACLE_HOME/precomp/demo/sqlディレクトリにあります。
Bug#1466269 プリコンパイル後にEXPLAIN PLANのヒントが消える
Bug#1323304 SPLIT文中のバックスラッシュが正常にエスケープされない
Bug#658837 SQLCHECK=FULLを指定してもUPDATE WHERE CURRENT OF文の無効な列が検出されない
Bug#2861151 カーソルFETCH後にORACAに正しい更新メッセージが表示されない
カーソルFETCH後にORACAで不正なメッセージが生成されていました。
修正により、FETCHがORACAに保存されていないことを示す正しいORACAメッセージが表示されます。
Bug#2838237 リテラルで三重バックスラッシュが使用されている場合にPROCでエラーが生成される
引用符付き文字列リテラルに三重バックスラッシュ（??/）が使用されていると、PROCでプリコンパイラ・エラーが生成されていました。
次に例を示します。
printf( "??/"Hello world.??/"??/n" );
printf( "??/"Hello ??/
world.??/"??/n" );
printf( "???/"Hello world.??/"?????/n" );
修正により、引用符付きリテラル文字列に使用されている場合にでも、三重バックスラッシュは正常に処理されます。
Bug#2838079 三重バックスラッシュと改行についてPROCでエラーが生成される
ソース・プログラムで三重バックスラッシュ（??/）と改行が使用されていると、PROCでプリコンパイラ・エラーが生成されていました。次に例を示します。 /* trigraph test program */
??=if !defined(__BOGUS1__) && ??/
!defined(__BOGUS2__)
typedef int xint;
??=endif
??=if !defined(__BOGUS1__) && ??/
!defined(__BOGUS2__)
typedef int yint;
??=endif
修正により、三重バックスラッシュと改行は正常に処理されます。
Bug#2765286 配列挿入を使用するとORA-01458が生成される
テストケースで配列挿入を使用すると、実行時にORA-01458エラーが生成されました。
次のコードでは、最初にCnt=1、次にCnt=5でORA-01458が生成されました。
EXEC SQL FOR :Cnt INSERT INTO TTGM0011 (COMPANY_CODE)
VALUES ( :stTTGM0011_ARR INDICATOR :stTTGM0011_ARR_IND ) ;
Bug#2717317 EXEC SQL CONTEXT ALLOCATEを使用するとメモリー・リークが発生した
EXEC SQL CONTEXT ALLOCATEをループ内で使用すると、メモリー・リークが発生しました。修正により、メモリー・リークは発生しなくなりました。
Bug#2688989 ループ内でsize=0を指定してsqlald()を使用するとメモリー・リークが発生した
ループ内でsize=0を指定してsqlald()を使用するとメモリー・リークが発生しました。テストケースでは、size=0を指定してループ内でsqlald()をsqlclu()とともに使用したところ、実行時にメモリー・リークが発生しました。
Bug#2672965 動的4 SQLまたは他のカーソルを使用するProcアプリケーションでコア・ダンプが発生した
動的メソッド4のSQLおよび他の暗黙カーソルまたは明示カーソルを使用するProcアプリケーションでは、動的メソッド3の文のコア・ダンプが発生しました。
Bug#2668683 PL/SQLにバインド変数の配列を使用すると、フェッチするデータがないことを示すエラーまたはORA-01458が生成される
PL/SQLブロックでバインド変数の配列が使用されると、アプリケーションでフェッチするデータがないことを示すエラーまたはORA-01458が生成されます。
Bug#2657920 マルチスレッド化されたPro*C/XAアプリケーションでローカルORACAを使用するとスタックが破損する
マルチスレッド化されたPro*C/XAプログラムでローカルORACAを使用すると、スタックが破損し、ロールバック/コミット時にセグメンテーション・エラーになり、この不具合が発生します。
Bug#2630986 65536以上の要素を持つ配列、コレクションは失敗する
アプリケーションで配列またはコレクションに65536以上の要素が使用されていた場合、正しい数の要素が処理されず、メッセージは表示されません。
Bug#2601507 SQLコマンドの関数コードが正常に戻らない
Prepareの後にチェックすると、sqlgls、SQLStmtGetTextは正しい関数を戻しませんでした。
Bug#2513269 #elif内で\の後に空白を使用するとPROCでエラーが生成される
#elifプリプロセッサ・ディレクティブで\の後に1つ以上の空白を使用すると、PROCでプリコンパイラ・エラーが生成されました。ほとんどの（すべてではなく）Cコンパイラは、この構文を受け入れません。ただし、今回の修正によりPROCではテストケースが正常にプリコンパイルされており、この構文がサポートされない場合にはコンパイラ側でエラー・フラグが設定されます。
Bug#2460104 UPDATE文に対してORA-24391が生成された
一部のプラットフォームでは、DML文（UPDATEなど）で暗黙カーソルがスクロール可能であると誤って想定され、ORA-24391エラーが生成されました。修正により、DML文の場合、カーソルはスクロール可能として扱われません。
Bug#2447771 pls-s306を使用するとCALL文のプリコンパイルに失敗する
sqlcheck=semanticsを指定してPROCアプリケーションをプリコンパイルすると、pls-s-306では、バインド変数として配列を取るプロシージャを含むCALL文が失敗します。PL/SQLブロック内でコールすると、同じ条件で正常に動作します。
Bug#2438825 PROCデモcpdemo2.pcが断続的に停止する
PROC接続プーリングのデモ・プログラムcpdemo2.pcは断続的に停止します。
Bug#2419715 構成ファイルで"INCLUDE AND SYS_INCLUDE"オプションを指定すると失敗する
CONFIGファイル内のオプションは、引用符を使用すると予期したとおりに動作しません。
Bug#2403646 Pro*Cアプリケーションがエラー（ORA-01722）の後で低速になる
「数値が無効です。」などのエラーが発生した後は、アプリケーションのパフォーマンスが低下しました。
Bug#2391185 不正なエラー・メッセージORA-00001が戻された
不正なエラー・メッセージORA-00001が戻されました。エラー発生時に記録されなかったORA-01012が戻されるかわりに、不正なエラーORA-00001が戻されました。
Bug#2377393 #includeの後にC++スタイルのコメントがあるとPROCプリコンパイラ・エラーが生成された
ソース・コードで#includeの後にC++スタイルのコメントが使用されていると、PROCでコンパイラ・エラーが生成されました。#define X <stdio.h>
#include X // ...,...
これは、C99規格による新規の要件です。Bug#2322384 EXEC SQL OBJECT GETでメモリー・リークが発生した
ループ内でOBJECT GETが実行されると、メモリー・リークが発生しました。修正により、メモリー・リークは発生しなくなりました。
Bug#2300956 カーソル変数を使用したSQL文のコア・ダンプが発生した
カーソル変数を使用するSQL文で、カーソル変数の前に他のバインド変数も含まれていると、実行時にコア・ダンプが発生します。
Bug#2296922 大きいSQL文が実行時に失敗してエラーORA-00972が戻された
大きいSQL文の実行がエラーになると、次に大きいSQL文は失敗し、「識別子が長すぎます。」というエラー（ORA-00972）が戻されます。
Bug#2296498 プロンプトに対して対話形式でパスワードを入力すると、PROCでコア・ダンプが発生する場合がある
プロンプトに対して対話形式でパスワードを入力すると、PROCでコア・ダンプが発生する場合がありました。修正により、コア・ダンプは発生しなくなりました。
Bug#2245086 非常に大きいバインド構造体を含むソース・コードをプリコンパイルするとPro*Cがクラッシュする
バインド変数または標識変数の詳細を保持するために割り当てられた一時バッファが小さすぎるために、100個以上のバインド変数または標識変数があると、内部のバインド/標識IDを保持できません。
Bug#2191497 エラー発生時に暗黙カーソルがクローズされない
release_cursor=yesを指定して暗黙カーソルを使用すると、エラーがあってもカーソルはクローズされませんでした。
埋込みSQL文でWAIT nやCASE ... WHEN ...などの新規SQL構文を使用すると、PROCでプリコンパイラ・エラーが生成されました。今回の修正以外にも、この問題は適切な動的SQLメソッドを使用してテストケースで処理されています。
Bug#2093408 *CASE WHEN*または*FOR UPDATE OF ... WAIT ..*を指定してSELECTをコンパイルすると失敗する
Bug#2083243 データベースの再起動後に記述子を割り当てるとコア・ダンプが発生した
アプリケーションで記述子の割当てまたは割当て解除の実行中にデータベースが停止され再起動されると、記述子の割当て中にコア・ダンプが発生します。
Bug#1991925 NCHARについて記述子項目を取得すると不正な値が戻される
ANSIの動的SQLを使用してNCHAR列からデータを選択すると、LENGTH、RETURNED_LENGTH、OCTET_LENGTHについて不正な値が示され、8進の長さが戻されました。
Bug#1923593 32ビット静的ライブラリでLOBDEMO1実行可能ファイルを実行するとコア・ダンプが発生する
lobdemo1を実行すると、常にバッファのオーバーフローが発生します。バッファcurdateが小さすぎて14バイトのデータをコピーできません。そのため、curdateの長さを大きくしました。
Bug#1754786 LOBロケータの配列に戻るDMLでコア・ダンプが発生した
DMLのRETURN句を使用してLOBロケータの配列に値を戻すと、コア・ダンプが発生しました。
Bug#1192868 名前付き接続の後に記述子を割り当てると失敗し、エラーORA-01012が戻された
名前付き接続を使用して接続し、記述子を割り当てようとすると、割当てに失敗してエラーORA-01012が戻されました。
ループに1つFETCH文がある場合、リリース8.0に比べてリリース8.1のパフォーマンスが低下しました。これは、すべての反復でホスト変数ごとに不要なDEFINEがコールされるためでした。修正により、すべてのホスト変数が解析され定義された後の同じFETCH文では、次の反復時にはDEFINEがコールされません。
Bug#1410679 標識変数がない場合に配列フェッチのパフォーマンスが低下した
標識変数を使用しない配列フェッチの場合は1行に対してフェッチが実行され、リリース8iではデータのフェッチを目的としたサーバーへのラウンドトリップ回数が増加していました。
修正により、FETCHのコール回数がリリース8.0.6と同じになっています。
Bug#1410582 ループ内でオブジェクトの割当てと解放が実行されるとメモリー・リークが発生した
ループ内でオブジェクトの割当てと解放が実行されると、メモリー・リークが発生しました。修正により、メモリー・リークは発生しなくなりました。
Bug#1390597 ORA-00001でエラー・メッセージとともに列名が出力されない
有効なエラー・メッセージORA-00001が生成される場合は、次のように列名のないエラー・メッセージが出力されていました。ORA-00001: 一意制約（.）に反しています。
修正により、エラー・メッセージは次のように出力されるようになりました。ORA-00001: 一意制約（SCOTT.SYS_C002621）に反しています。
Bug#1239856 sizeofを使用するとPROCでプリコンパイル・エラーが生成された
ホスト変数の型を解決するときにsizeofが使用されると、PROCでプリコンパイラ・エラーが生成されました。修正により、同じホスト変数についてsizeof式が実際には評価されないことを示す警告が生成されます。
次に例を示します。
char dst[1024] ;
char dyn_statement[sizeof(dst)];
EXEC SQL VAR dyn_statement IS STRING(1024);
次の警告メッセージが生成されます。
Semantic error at line 61, column 27, file t1239856.pc:注意: 使用例によっては、アプリケーションが意図したとおり動作しない場合があります。そのため、ホスト変数の型にはsizeofを使用しないことをお薦めします。
Bug#1175132 INSERTに不要な解析が実行されるためパフォーマンスが低下した
INSERT文が原因でORA-00001エラーが発生するたびに、INSERT文の再解析がトリガーされ、パフォーマンスが低下します。ORA-01403、ORA-01405およびORA-01406の場合にのみ、再解析は実行されませんでした。修正により、解析エラーが発生しないかぎり再解析は実行されません。
Bug#897697 Pro*C/C++でUSING句を含む関数を変換できない
変換関数にUSING句を使用すると、Pro*C/C++ではプリコンパイル時にPCC-S-02201エラーが発生しました。
Bug#746347 動的SQLメソッド4で不正なsqlerrd[4]値が生成された
動的SQLメソッド4で、エラーがある列の番号を指す不正なsqlerrd[4]値が生成されました。修正により、sqlerrd[4]に正しい値が割り当てられます。
Bug#927164 RELEASE_CURSOR=YES HOLD_CURSOR=NOを指定するとORA-02103が発生した
RELEASE_CURSOR=YESおよびHOLD_CURSOR=NOオプションを使用してアプリケーションを作成すると、実行時にORA-02103が発生しました。このエラーの原因は、再利用しようとしているときにカーソルの一部の要素を解放したことです。この問題を修正するために、適切な条件が設定されました。
Bug#922250 生成されたファイルに行の継続を表す\がない
Pro*C/C++では、行継続文字\のない不正コードが生成される場合がありました。
Bug#909074 大文字のファイル名を使用して小文字のインクルード・ファイルをオープンできない
Pro*C/C++では、実際には小文字のインクルード・ファイルをオープンするときに大文字のファイル名を使用すると、「PCC-S-02015: 挿入ファイルをオープンできません。」というエラーが生成されました。
Bug#872814 NCLOBデータに対してEXEC SQL READを実行するとORA-24806エラーが戻される
埋込みSQL LOB READ（およびWRITE）文でNCLOBを使用すると、アプリケーションで「ORA-24806: LOBのフォームが一致しません。」が生成されました。
Bug#850965 ポインタ/非ポインタのホスト/標識構造体が混在する問題
Pro*C/C++では、対応する非ポインタのホスト構造体と混在しているポインタの標識構造体を処理できません。次に例を示します。
typedef struct { .. } hst;
typedef struct { .. } ind;
hst h;
ind i, *ip = &i;
EXEC SQL SELECT .. INTO :h:ip FROM ..;
ホスト/標識構造体のペアが混在し、一方がポインタで他方がポインタでないと、セマンティクス・プリコンパイル・エラーになります。
Bug#826057 64ビットのポートではANSIの動的SQLオプションtype_codeが失敗する
64ビット・プラットフォームでは、TYPE_CODEオプションを値ANSIに設定してANSI動的SQLで使用すると、不正な結果が戻されました。
Bug#821874 AT句を使用するとSQLUS.MSBに余分なファイル記述子が使用された
CONNECT文にAT句を使用すると、SQLUS.MSBメッセージ・ファイルがオープンされますが、これは不要です。修正により、エラーが発生するまでSQLUS.MSBのオープンは遅延するようになりました。
Bug#791384 NULLのLOBにLOBを追加すると、説明的でないエラー・メッセージが戻される
NULLのLOBに対するLOBのAPPENDはエラーです。ただし、SQLLIBから戻されるエラー・メッセージには、この状況が正しく記述されませんでした。
Bug#764996 INSERT文で表の別名を使用できない
INSERT文で表の別名を使用すると構文エラーになります。次に例を示します。
EXEC SQL INSERT INTO persons p VALUES ..
RETURNING .. INTO .. ;
表の別名pはPro*C/C++に受け入れられず、構文エラーとなります。
Bug#761892 Pro*C/C++で接続修飾子が認識されない
Pro*C/C++では、表の参照に使用されている接続修飾子を解析できませんでした。次に例を示します。
EXEC SQL SELECT .. INTO .. FROM sys.dual@v7bug.world@q1;
この場合、接続修飾子を示す@が使用されているため構文エラーとなります。
Bug#693939 ANSIの動的SQLでは空白埋め文字列型が埋められない
文字列型、ANSIの可変文字列型およびANSIの固定文字列型は、ANSI動的プログラムで使用されると空白で埋められませんでした。修正により空白で埋められるようになり、戻される長さフィールドは不定です。
Bug#690984 Pro*C/C++では、長さを16進値で指定するとホスト・フィールドの長さが0（ゼロ）とみなされる
Pro*C/C++では、16進（または8進）定数を使用して宣言されたCHARまたはVARCHARホスト変数の長さが正しく処理されませんでした。たとえば、変数の長さchar x [ 0 x 40 ] は値0（ゼロ）として計算されるため、SQL文中で使用されると失敗しました。
Bug#606462 CHARFと等価のCHAR変数に長さ1が使用されない
1つのCHAR変数と等価の型をCHARFに割り当てると（つまり、char x に続いてexec sql var x is charf;を使用 -- 長さ指定がないことに注意）、ホスト変数に長さ1ではなく0（ゼロ）が誤って割り当てられ、埋込みSQL文に使用された場合は不正データとなりました。
Bug#319566 ANSIスタイルの複数行のコメント（--）があると失敗してPCC-S-2201が戻される
埋込みSQL文にANSIスタイルの複数のSQLヒントを使用すると、構文エラーになりました。次に例を示します。
EXEC SQL SELECT --+ hint comment 1
--+ hint comment 2
... INTO ... FROM ...;
この例は、プリコンパイル時に構文エラー・メッセージが生成されます。回避策は、かわりに/*+ .. */ヒント書式を使用することでした。
Bug#701934 Pro*Cでオブジェクトとともに不適切な標識変数を使用するとコア・ダンプが発生する
Pro*Cでは、Object Type Translatorで型が生成されていない標識変数を、なんらかのObject型のホスト変数（つまり、OTTにより型が生成されたホスト変数）とともに使用すると、コア・ダンプが発生します。
Bug#544522 Pro*Cがバインド変数内の算術式を受け入れない
Pro*Cは、算術式の使用に関係したバインド変数式を受け入れません。次に例を示します。
EXEC SQL UPDATE tab SET col = :x [ i + 1];
Pro*Cでは、i+1の式で式の型が使用方法と一致しないことを示すエラーが発生します。
修正により、Pro*Cは、+、-、*、/および%演算子のみが使用されている場合、一定の算術式を受け入れるようになりました。
Bug#692782 SQL_CURSOR変数へのポインタがALLOCATEまたはFREEで機能しない
EXEC SQL ALLOCATE文またはFREE文にSQL_CURSOR *型のホスト変数を使用すると、実行時にセグメンテーション・エラーになります。この2つの文で正常に動作するのは、非ポインタのSQL_CURSORホスト変数のみです。FETCHやCLOSEなど、他の文にSQL_CURSOR *型のホスト変数を使用すると、問題なく動作することに注意してください。
Bug#692548 Pro*Cで配列を含む構造体へのポインタを処理できない
SELECT文またはFETCH文で配列を含む構造体へのポインタがホスト変数として使用されると、配列サイズに関係なく1行しか取得されません。このため、SELECT文の場合は「SQL-02112: SELECT..INTOが戻す行が多すぎます。」が戻ります。FETCHの場合はFOR句を使用すると問題を回避できますが、SELECT文にはFOR句を使用できません。次に例を示します。
struct foobar { int empno[14]; } a, *b;
b = &a;
EXEC SQL SELECT empno INTO :b FROM emp;
この場合はSQL-02112エラーとなります。:aにSELECTすると正常に動作します。構造体が名前付きであるという事実が関係していることに注意してください。名前のない構造体を使用するとエラーは発生しません。事実、どちらの場合も名前のない構造体ポインタは正常に動作します。
Bug#668920 CURSOR副問合せとMULTISET副問合せでORDER BY句が受け入れられない
Pro*Cでは、CURSOR副問合せまたはMULTISET副問合せの一部としてORDER BY句が使用されていると、構文エラーが生成されます。次に例を示します。
EXEC SQL SELECT CURSOR(SELECT ename FROM EMP
WHERE deptno = :deptno
ORDER BY ename)
FROM DUAL;
ORDER BY句はオプションであり、CURSOR副問合せまたはMULTISET副問合せで許可する必要があります。
Bug#642112 接続が有効であってもSQLLIBでORA-01012（接続されていません）が戻される
埋込みSQL CONNECT文を介して接続されていない場合は、SQLLIBでORA-01012エラー・メッセージが戻されました。
Bug#638215 REFインジケータが正常に動作しない
REFインジケータが正しく設定されませんでした。次に例を示します。
EXEC SQL SELECT ref_column
INTO :ref_hostvar:ref_indvar FROM tab WHERE .. ;
このような文ではORA-01405が戻されます。
Bug#636898 マルチスレッド化アプリケーションで接続/切断のペアに対してメモリー・リークが発生することがある
マルチスレッド化アプリケーション（threads=yesを指定してプリコンパイルされ、EXEC SQL ENABLE THREADSを実行したアプリケーション）では、EXEC SQL CONNECTとEXEC SQL <ROLLBACK | COMMIT> RELEASEが繰り返し実行されると、メモリー・リークが発生することがあります。
Bug#636325 CONNECT文に新規のSYSDBA、SYSOPER構文が追加された
8.0.4より前のリリースでは、デフォルトで次のように埋込みSQL CONNECT文を使用して、SYSDBA権限とパスワードCHANGE_ON_INSTALLで識別されたユーザーSYSに接続できました。
EXEC SQL CONNECT :uid IDENTIFIED BY :pwd;
リリース8.0.4では、接続モードを指定する必要があるため、この埋込みSQL CONNECT文は失敗します。リリース8.0.5のPro*C/C++では、次のように新規の埋込みSQL CONNECT構文を使用して接続モードを指定できます。
EXEC SQL CONNECT :uid [ IDENTIFIED BY :pwd ]
[ AT [ : ] dbname [ USING: hst ] ]
{ [ ALTER AUTHORIZATION: newpwd] | [ IN { SYSDBA | SYSOPER } MODE ] }
制限:
AUTO_CONNECT機能を使用している場合は、SYSDBA/SYSOPERモードで接続できません。Bug#622811 RELEASE_CURSOR=YESオプションを使用するとメモリー・リークが発生する
カーソルのクローズ時にメモリー・リークが発生しました。
Bug#621712 Pro*Cでextern "C"構成メンバーの解析中に構文エラーが生成される
extern "C"構成メンバーを持つDECLARE SECTIONにヘッダー・ファイルを置くと、構文エラーになりました。明示的なDECLARE SECTION内にあるとPARSEがFULLに設定されるため、CODE=CPPまたはPARSE=PARTIALを指定しても問題が発生します。CODE=CPPの場合は、Object Type Translator（OTT）により生成されるヘッダー・ファイルをDECLARE SECTION内にインクルードする必要があるため、OTTにより生成されるヘッダー・ファイルを使用してC++アプリケーションを作成しようとすると問題が発生します。それ以外の場合、重要な型定義はPro*Cで解析されません。通常は、extern "C"構文を次のように#ifdefで囲みます。
#ifdef __cplusplus
extern "C" {
#endif
Pro*Cでは、CODE=CPPのときには__cplusplusが内部的に定義されるため、簡単な回避策の1つは次のようにORA_PROCマクロを使用して条件付きで#undefすることです。
#ifdef ORA_PROC
# undef __cplusplus
#endif
この場合、extern "C"構文の使用場所に関係なく（DECLARE SECTION内かどうかに関係なく）解析されません。生成されたCコードがC++コンパイラでコンパイルされるときには、extern "C"コードが認識され、問題なくコンパイルされるように、ORA_PROCはプリコンパイル中にのみ定義する必要があります。
Bug#607962 IAF PUT VALUESに対して「'」のかわりに不正な文字列「''」が生成される
IAF PUTまたはTOOLS MESSAGEあるいはTOOLS SET文でリテラル文字列の一部として「''」が使用されていると、コードが正常に生成されませんでした。
次に例を示します。
EXEC IAF PUT GLOBAL.MSG_TXT VALUES('WHO''S THERE?');この場合は、正しい文字列WHO'S THERE?のかわりに文字列WHO''S THERE?を含む不正なコードが生成されます。
Bug#588979 Pro*Cではderef時にオブジェクトのインジケータ構造体がフェッチされない
Pro*Cではderef時にオブジェクトのインジケータ構造体が取得されませんでした。回避策は、SQLEnvGetで提供される環境でOCIObjectGetIndを物理的に使用することでした（Pro*CのOCI相互運用性の問題を参照）。
Bug#588392 SQLLIBでコンテキストの割当てと解放の間にメモリー・リークが発生する
ランタイム・コンテキストを割り当てて解放したPro*Cアプリケーションで、ALLOCATEとFREEのペアをコールするたびにメモリー・リークが発生しました。
Bug#579807 Pro*Cで処理するSQL文が長すぎるとコア・ダンプが発生する
Pro*Cでは、長すぎるSQL文（複数の入力行にまたがるSQL文）は正常に処理できません。簡単な回避策は、文を複数の継続行にまたがらせるのではなく、改行を挿入してSQL文を分割することでした。
Bug#571769 PROCで#defineに#machineを使用できない
Pro*Cは、特に他のマクロの#defineに使用されている場合に、#machineディレクティブを正常に処理できません。次に例を示します。
#define __mips__ #machine(mips)
__mips__の予期値が適切に定義されないため、プリコンパイル中に他のエラーが発生します。#machineディレクティブはできるかぎり使用しないでください。
Bug#558787 Pro*Cでは複合的なホスト変数式の型を解決できない
( *x ).y または ( *x ) -> y 形式のホスト変数式の型は、Pro*Cでは解決できません。通常、カッコで囲まれたホスト変数式はPro*Cで受け入れられません。
制限:
ホスト変数式が左辺値でなくても、Pro*Cでは警告が表示されません。また、このように複合的な式はスカラーまたは配列に解決する必要があることに注意してください。Pro*C/C++では、構造体に解決される複合的なホスト変数式を処理できません。
Bug#556949 MODE=ANSIを指定してプリコンパイルするとパフォーマンスが低下する
ANSIでは、カーソルを再OPENする前にCLOSEする必要があります。そのため、MODE=ANSIを指定してプリコンパイルしたアプリケーションは、カーソルが何度もCLOSE/再OPENされると、OPENするたびに再解析されるため低速になる場合があります。この種のアプリケーションでは、OPENされているカーソルをすべてCOMMITでクローズします。
アプリケーション開発者がCOMMITの実行時にカーソルをCLOSEするかどうかを選択できるように、新規のCLOSE_ON_COMMITオプションが追加されています。CLOSE_ON_COMMIT=NOに設定すると、COMMITの実行時にもカーソルがクローズされないため、再OPENの必要性が減少し、余分な解析も減少するため、パフォーマンスが向上します。
Bug#553658 NLS_CHARとNLS_LOCALを使用するマルチスレッド化アプリケーションでGPFが発生する
Windows NTプラットフォームでは、プリコンパイラ・オプションnls_charおよびnls_localを使用したアプリケーションでコア・ダンプが発生しました。Windows NTのマルチスレッド化アプリケーションの場合、グローバル・ランタイム・コンテキストは適切なnls_charおよびnls_local情報を取得しないために、コア・ダンプが発生しました。
Bug#549812 コマンドラインで指定した複数のファイル名を処理中にコア・ダンプが発生する
ファイル名として3つ以上の名前（x x xなど）を指定すると、Pro*でコア・ダンプが発生しました。Pro*はコマンドライン・オプションを処理するときに、入力ファイル名1つと出力ファイル名1つを想定しています。コマンドラインで3つ以上のファイル名を指定でき、適切なエラー・メッセージが表示されるように、Pro*が修正されました。
Bug#549142 PREPARE文またはIMMEDIATE文に使用した%文字が削除される
PREPARE文またはIMMEDIATE文でLIKE比較に%文字を含むテキストを引用符なしで指定すると、出力ファイルに生成されませんでした。次に例を示します。
EXEC SQL PREPARE s_pln_count FROM
SELECT COUNT(*) FROM PLN
WHERE plan_type LIKE 'LOAN%';
この例では、次の出力が生成されます。
sqlstm.stmt="select count(*) from PLN where plan_type like 'LOAN'";値0（ゼロ）のカウントが戻されます。
正常に生成されたコードは次のようになります。
sqlstm.stmt="select count(*) from PLN where plan_type like 'LOAN%'";Bug#502066 長い.pcファイル名のプリコンパイル時にコア・ダンプが発生する
コマンドラインでLNAMEおよびLTYPE=LONGオプションとともに長い（101文字以上の）.pcファイル名を使用すると、メモリーが破損してコア・ダンプが発生しました。ファイル名のサイズを静的に割り当てるかわりに、動的な長さを使用します。
Bug#458658 ##マクロ定義に#演算子を使用する場合の問題
Pro*Cでは、##操作の本体に#演算子が使用されているマクロ定義を解析できません。次に例を示します。
#define strcat(x) #x ## "foo"
Pro*Cでは構文エラーが生成されます。修正により、Pro*Cはこの種の構文を受け入れますが、テキストの文字列化との連結は実行されません。
Bug#393628 特定の複合マクロ定義の構文エラー処理
Pro*Cでは、次の書式のマクロ定義を処理できません。
#define __P(x) x
#define foo(x) something(x, 10)
extern int foo __P((int))
この問題は、fooマクロが認識されてextern宣言内で拡張されるように、以前は(int)に拡張されなかった__Pが使用されていることが原因でした。
また、次の書式のマクロ
#define __ARG1(t1, x1) (t1) t1 x1;
および、そのマクロをサブプログラムの作成に使用する場合にも問題が発生しました。まれに、この種のマクロに必要なマクロ拡張が原因で構文エラーとなることがあります。Bug#316344 SQLヒントの位置が不正な場合のエラーを含むプリコンパイル
Pro*Cでは、SQLヒントが不正な位置で使用されているSQL文は正常にプリコンパイルされません。生成された文には、通常、ヒントのテキストが誤って文の残りの部分に混在し、その結果実行時エラーとなります。SQLヒントには/*+ .. */および--+形式を使用し、SELECT、UPDATE、INSERTまたはDELETEの各キーワードの直後に使用する必要があります。他の位置にあるヒント・コメントはエラーであり、プリコンパイラにより構文エラー・フラグが設定されます。このため、ヒントを使用する場合は、ヒントが文の実行に影響すると考え、それを受け入れて無視するのではなく適切に使用する必要があります。
Bug#552084 Pro*Cを介したデータベースへのログオン試行に失敗しても、シャドウ・プロセスがサーバーに残ったまま終了しない
それ以後にログオン試行に失敗すると、プログラム自体が終了するか、サーバーがプロセスをすべて使用するまで、新規のシャドウ・プロセスが残ります。
Bug#546237 接続文字列にユーザー名に関連付けられた明示的データベース名を使用すると、データベースに接続できない
たとえば、scott@remoteとして接続しようとすると失敗し、ORA-01017エラーが戻されます。
Bug#523931 各種INSERT文の後にWHENEVER NOT FOUND条件がチェックされない
たとえば、NO DATA FOUNDを戻したINSERT文のPL/SQLトリガーは、WHENEVER NOT FOUND条件でトラップされません。
Bug#515582 文字列リテラルがバインド変数式として使用されるたびにPro*Cでコア・ダンプが発生する次に例を示します。
EXEC SQL SELECT job INTO :job FROM emp WHERE ename = :"KING";
バインド式としての文字列リテラルの使用は無効であり、プリコンパイラによりエラー・フラグが設定されます。
Bug#509647 ナビゲーショナルOBJECT SET文で属性の前にコロンがないとコア・ダンプが発生する
ただし、これはOBJECT GETでは発生しませんでした。
Bug#508256 プラットフォームによっては、問合せでDEREF()またはREF()を処理するとPro*Cでコア・ダンプが発生する
Bug#506520 Pro*CでINSERT文に有効なSQLヒントが使用されている場合に構文エラーが生成される
どのような書式のINSERT文でも、有効なヒントがあるとこの種のエラーが発生します。
Bug#503981 Pro*CではPL/SQLブロックを実行する動的SQLメソッドを含むホスト配列を正常に処理できない
Bug#286765 動的SQLを介してホスト配列をPL/SQL表にバインドすると実行時エラーが発生する
動的SQLメソッド2のEXEC SQL EXECUTE文に使用されているホスト配列は、ARRAYLEN文に新規のオプション・キーワードEXECUTEが使用されているかどうかに応じて、2つの異なる方法で解析されます。
詳細は、リリース8.0.4の『Pro*C/C++ Precompiler プログラマーズ・ガイド』を参照してください。
Bug#217428 VARCHAR2(2000)型の表に2つの列があると、許可されない2つのLONG列と誤ってみなされる
このため、表の複数のVARCHAR2列にこのサイズを使用してアプリケーションを開発することはできません。
Bug#472139 Pro*CではPARSE != FULLのときに同値化された変数が処理されない
Pro*Cでは、PARSEオプションの値がFULLに設定されていない場合、データ型が同値化された変数は処理されません。次に例を示します。
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 = ..;
indは実際にはポインタであるため、生成されるコードはindを直接参照するのではなくind(&ind)のアドレスを取ります。この問題が発生するのは、PARSE != FULLの場合のみです。
Bug#471975 ORACAで保存された文のテキストを使用して解放されたメモリーからの読取りが可能である
ORACAを使用して文テキストを要求したプリコンパイラ・アプリケーションでは、動的SQLも使用しているとメモリー・リーク関連の問題（コア・ダンプなど）が発生することがあります。この問題は、文テキストを保持するために使用されたホスト変数が、動的に割り当てられたメモリー（割当後に解放される）を示す場合か、またはホスト変数が自動変数の場合によく発生しました。この不具合修正の副次効果として、プリコンパイラにより解析される文の後にsqlgls()をコールすると、古い文テキストを戻さなくなりました。次に例を示します。
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 */
Bug#471039 Pro*CでDELETE文のSQLヒントが正常に処理されない
Pro*Cでは、SQLヒントが使用されないようにDELETE文が並べ替えられます。次に例を示します。
exec sql delete /*+ INDEX (emp emp_idx) */ from emp ..
=> "delete from /*+ INDEX (emp emp_idx) */ emp .."
Pro*Cではヒントの位置が変更され、文の実行中には使用されなくなります。
Bug#465932 Pro*Cでは#errorディレクティブ内に単独の「'」が許可されない
Pro*Cでは、プリプロセッサ・ディレクティブ内の単一の「'」はSQL文字列リテラルの開始として扱われます。
#error This didn't work
そのため、この#errorディレクティブを解析すると、終了文字のないSQL文字列に関するエラーが表示されます。
Bug#443347 動的配列を実行する前にプリコンパイルすると不正な結果となる
動的な配列挿入に使用するINSERT文をプリコンパイルした後に、PL/SQLブロックを含む他の文をプリコンパイルすると、実行時には1行しか挿入されません。
Bug#414511 Pro*Cでディレクティブ内で行継続文字の後の空白が許可されない
プリプロセッサ・ディレクティブ内で行継続文字と改行文字を区切る空白は、Pro*Cでは無視されません。次に例を示します。
この場合は、プリコンパイルの前処理フェーズでプリコンパイル・エラーになります。Pro*Cでは、このような余分な空白が無視されるようになりました。
Bug#408116 マルチバイト・キャラクタを含む/*+コメントがあるとPro*Cでコア・ダンプが発生する
Pro*Cでは、マルチバイト・キャラクタの可能性は考慮されていないため、/*+コメントにマルチバイト・キャラクタが含まれているとコア・ダンプが発生します。
Bug#406516 コマンドライン・オプションに関する長いPCC-F-02135メッセージが切り捨てられる
インクルード・ファイルなど、ヘルプ・オプションの値が非常に長い場合にこの種のオプションのヘルプ・メッセージを表示すると、値の一部しか表示されず、セグメンテーション・エラーが発生することがあります。
Bug#402136 VARCHAR変数でNULLを挿入するとORA-01459が戻される
長さ0（ゼロ）の文字列を指すVARCHARポインタがデータベースに挿入されると、「ORA-01459: 可変長文字列の長さが無効です。」というメッセージが戻されます。
Bug#400907 オプション値が81文字以上の場合にプリコンパイラが停止する
オプション・リストを使用する場合に、リストの値の長さが合計80文字を超えていると、プリコンパイラが停止します。
Bug#397811 配列DMLの配列サイズがAT :database句と一致しない
Pro*Cでは、AT :database句があると、同等ディメンションのホスト配列を含むDML文について配列サイズの不一致エラーが戻されます。AT句のDBNAMEは、それ自体がスカラーのホスト変数であり、不一致の原因となっていたことに注意してください。
Bug#397223 ディメンション化されていない配列の特定の要素を参照できない
これは、ディメンション化されていない配列の特定の要素がEXEC SQL文にホスト変数として使用されていると、プリコンパイラ・エラーになるという問題でした。プリコンパイラ・エラーは、215929のコア・ダンプを修正するために生成されました。この修正によりプリコンパイルなしでコア・ダンプが削除され、適切なプリコンパイルと実行が進行します。
Bug#382795 Pro*Cで#define ident 'LOTTO'ディレクティブを解析できない
#define ident Bを使用すると、Pro*Cではidentがあるためエラー・フラグが設定されました。これは、#defineにはキーワードが許可されないためです（一部のプラットフォームではidentがキーワードとして使用されることを示すためです）。そこで、if、ifdefなど、他のキーワードと同じidentの使用方法に対処するために、構文規則が変更されました。
Bug#371255 ポインタが無効でもインジケータがNULLの場合にセグメンテーション・エラーが発生する
バインド変数のポインタが無効で、関連付けられたインジケータが-1に設定されている場合は、アクセス違反が発生します。
Bug#366775 THREADS=YESを指定してプリコンパイルするとコア・ダンプが発生し、テンポラリ・ファイルが削除されない
ただし、ユーザーは、コア・ダンプが発生しないようにTHREADS=YESを機能させるためのコードを記述する必要があります。この修正により、セマンティクス・エラー・メッセージが生成され、テンポラリ・ファイルが削除されます。たとえば、この不具合で提供されるテストケースでは、次のエラー・メッセージが生成されます。
(1) PCC-F-02390: EXEC SQL CONTEXT USE文が見つかりません。
Bug#359035 NLS: コメント行の生成時に列の位置が不正です
CHARストリームにNLS文字が存在する場合は、マルチバイトの関係で列のカウントを訂正する必要がありました。たとえば、ストリームに45文字があり、そのうちの2つがNLS（マルチバイト）の場合、実際には43文字しかありません。45文字が使用されると次の2バイトがフェッチされますが、それがコメント/*の開始となることがあります。これにより、コメント構造全体が乱れます。そこで、この修正により正しい文字数が計算されます。
Bug#345010 Pro*CではANSIトークン・マージ演算子の使用を処理できない
マージ演算子##を使用すると、Pro*Cで擬似的な構文エラー・メッセージが生成されます。この構文は受け入れられるようになりましたが、マージは実行されません。Pro*Cは、この演算子の使用は受け入れますが、機能をサポートしません。
Bug#344346 一部のNLS言語でプリコンパイラのヘルプ画面が無限ループに入る
一部のNLS言語では、コマンドライン・オプションの説明が長すぎて1行に収まらず、多数の空白を挿入しなければ複数行に分割できないため、ヘルプ画面を要求すると、プリコンパイラが無限ループに入ります。
Bug#268198 Pro*CでEXEC SQL BEGIN_END DECLARE SECTIONの分割が許可されない
Pro*Cでは、EXEC SQL BEGIN/END DECLARE SECTION全体を、複数行になる可能性があっても1行に記述する必要がありました。他の場合には構文エラーになります。
Bug#479063 LOB型の配列を使用すると擬似的な実行時エラーが発生する
プリコンパイラでは、LOB型の一定の配列宣言を処理するとき、特に、関数のパラメータ・リストに指定されている場合に、不正なコードが生成されました。たとえば、次の文は正常にプリコンパイルされませんでした。
void BlobFunc(multi_blob)
OCIBlobLocator *multi_blob[ ];
Bug#475284 Pro*Cで特定のエラー・メッセージの生成後にコア・ダンプが発生する
Pro*Cでは、一部の新規Objects関連型（OCINumber）として宣言されたバインド変数の使用に関連して、一定のエラーが検出された後にコア・ダンプが発生します。この問題は、INTYPEファイルを指定せずにObjectsプログラムをプリコンパイルした場合にも発生します。
Bug#469671 Pro*Cでマルチバイトの長いテキスト行の処理中にコア・ダンプが発生する
多数のマルチバイト・テキストを含む長すぎる入力行があると、Pro*Cではコア・ダンプが発生して異常終了します。
Bug#464714 FIPSレポートにすべての違反が行0（ゼロ）で発生したことが示される
Pro*Cにより生成されたFIPSレポートは、実際に違反が発生したプログラムの実際のソース行ではなく、すべての違反が行0（ゼロ）で発生したことを示します。
Bug#463066 Pro*Cでは等価文内でCの式が許可されない
Pro*Cでは、データ型等価文には、プリコンパイル時に評価可能な複合定数式は許可されません。
#define LENGTH 10
char x[ LENGTH+1 ];
EXEC SQL VAR x IS STRING( LENGTH + 1 );
修正により、VAR/TYPE文のSQLデータ型の長さ指定には、プリコンパイル時に数値に評価できる任意の定数式を使用できるようになりました。
Bug#461907 Pro*Cでは長さ指定のないLONG VARCHARに関するエラーが戻されない
LONG VARCHARデータ型には長さが必須です。Pro*Cは長さ指定のないLONG VARCHARを受け入れますが、実行時エラーとなります。
EXEC SQL VAR foo IS LONG VARCHAR;
この例は無効です。修正により、構文エラー・メッセージが生成されるようになりました。
Bug#454733 Pro*C/C++が副問合せのWITH句を受け入れない
副問合せへのWITH句の追加は、Oracle8の新機能です。Pro*CではWITH句は許可されていませんでした。かわりに構文エラーになります。たとえば、次の例は許可されていませんでした。
EXEC SQL INSERT INTO (SELECT ename, deptno FROM emp
WHERE deptno > 10 with check option)
VALUES ('Taylor', 20);
WITH READ ONLY句も許可されません。この問題を回避するには、かわりに動的SQLを使用する必要があります。
Bug#454727 Pro*Cが表の名前のPARTITION句を受け入れない
Pro*Cは、DML文で表の名前のPARTITION句が使用されていると、その構文を拒否します。次に例を示します。
EXEC SQL DELETE FROM sales PARTITION (nov96) WHERE ..
この問題を回避するには、動的SQLを使用する必要があります。
Bug#453328 SQLCHECK != FULLを指定するとPro*Cがuseridオプションを処理できない
Pro*Cは、SQLCHECKオプションがFULLに設定されていなければ、useridオプションの使用を許可しません。
Bug#434744 LTYPE=LONGの場合にリスト・ファイルにコマンドライン・オプションが追加されない
LTYPEコマンドライン・オプションをLONGに設定した場合は、現在のコマンドライン・オプションの値をリスト・ファイルに指定する必要があります。また、改ページ文字は、リスト・ファイルの1文字目ではなくページ間に使用する必要があります。
Bug#429924 Pro*CでWHENEVER文に使用されている「&」を処理できない
Pro*Cでは、WHENEVER文には&演算子を使用できません。次に例を示します。
EXEC SQL WHENEVER SQLERROR DO sql_error( &x );
理解しづらいエラーとなります。Pro*Cでは、この文が複合式の一種として受け入れられ、より適切に処理できるようになりました。
Bug#428633 Pro*CでWHENEVER文に単項式が許可されない
Pro*Cでは、WHENEVER文には単項式が許可されません。次に例を示します。
EXEC SQL WHENEVER SQLERROR DO sql_error( -1 );
すべての単項式が許可されるようになりました。ただし、現在、WHENEVER文では二項式はサポートされません。
Bug#426826 Pro*Cでは未定義の変数を割り当てるとコア・ダンプが発生する
未定義の変数を割り当てようとすると、Pro*Cでコア・ダンプが発生します。次に例を示します。
EXEC SQL ALLOCATE :undefined;
変数が未定義であることと、ALLOCATEで型エラーが発生したことを示す有効なエラーが生成されるようになりました。
Bug#406664 Pro*Cでマクロが名前になっているファイルがインクルードされない
Pro*Cでは、code=ansi_cまたはcode=cppの場合に#includeできるのは、マクロで定義されているファイルのみです。一部のkr_cコンパイラではこれが可能ですが、Pro*Cでは構文エラーとなります。
#define HEADER "file.h"
#include HEADER
このディレクティブが動作するのは、CODE=KR_CではなくCODE=ANSI_CまたはCODE=CPPの場合です。KR_CコンパイラではコンパイルされないANSI_C生成コードが使用されるため、実際の回避策はありません。
Bug#399274 Pro*CでSTART WITH ... CONNECT BYの順序が切り替わることがある
本来、Pro*Cでは、CONNECT BYが先に使用されている場合にも、常にSTART WITHの後にCONNECT BYが生成されます。このため、以降に明示カーソルで使用されるプリコンパイルされたSQL文の場合には、問題が発生します。文が逆の順序で生成されているため、結果的なOPEN USING <bind variable list>ではバインド変数が正しい順序で生成されない場合があります。これにより、プログラムの実行中に実行時の型不一致エラーとなります。
Bug#364746 Pro*Cで<table>.*の参照を使用するとC++エラーが発生する
Pro*Cでは、SQL文で有効な<table>.*の参照を使用していても、C++の記号の使用に関するエラーが戻されます。次に例を示します。
EXEC SQL SELECT emp.* INTO :emp_struct FROM emp;
回避策は、emp.を削除して単にSELECT *を実行することでした。1. OS/外部認証を介してローカルまたはリモートのマシンに接続してスレッド化するPro*Cアプリケーションは、CPOOLがYESに設定されているとORA-01005を戻して失敗します（Bug 2675900）。
これはOCIによる制限事項です。この問題の回避策は、プログラムの最初のCONNECT文としてダミーのEXEC SQL CONNECT :useridを使用することです（useridは、有効なデータベース・ユーザー名/パスワードです）。#includeと明示的なEXEC SQL INCLUDEの両方を使用してsqlca.hやsqlda.hなどのOracleヘッダー・ファイルをインクルードするプログラムは正常にプリコンパイルされず、コンパイルされないコードが生成されます。最も簡単な回避策は、できるかぎり#includeを使用し、古いEXEC SQL INCLUDE構文を併用しないことです。
次の表に、Pro*C/C++リリース8.0.3とリリース8.1.6の間に導入された新機能に判明している制限事項と不具合を示します。
| Oracle8の新規C型 | 埋込みSQLでのPro*C/C++ サポート |
バルク操作に対するPro*C/C++での サポート*1 |
埋込みPL/SQLでのPro*C/C++の サポート*2 |
|---|---|---|---|
OCINumber |
あり |
なし |
あり |
OCIString |
あり *3 |
なし |
なし |
OCIRaw |
あり |
なし |
あり |
OCIDate |
あり |
なし |
なし |
OCIRef *4 |
あり |
あり |
なし |
OCIBlobLocator |
あり |
あり |
あり |
OCIClobLocator |
あり *5 |
あり *5 |
あり *5 |
ユーザー定義型 *6 |
あり |
あり |
あり *7、*8 |
Nested Tables |
あり |
あり |
あり |
VARRAYS |
あり |
あり |
あり |
*1) この列は、所定のホスト型の配列であるバインド変数を使用した、複数行（バルク）の埋込みSQL操作に対するPro*C/C++のサポートを示します。
*2) 新規のC型の配列は、Pro*C/C++に埋め込まれたPL/SQLブロックではサポートされません。
*3) OCIString型のホスト変数は、ユーザー定義型内でのみサポートされます。オブジェクト型の文字属性がOTTによりC構造体のOCIStringフィールドにマップされる場合、Pro*C/C++ではオブジェクト全体を操作する操作にのみ使用できます。
現在、この種のOCIStringフィールドをスタンドアロンのバインド変数（リレーショナル表の列へのバインドなど）として個別に使用することはサポートされません。
*4) OCIRefホスト変数（Oracle8データベースでのREFを表す）は、埋込みSQL内とSQLCHECK=SYNTAXを指定したPro*C/C++モードでサポートされます。
ただし、埋込みPL/SQLブロック内、またはPro*C/C++コマンドライン・オプションSQLCHECK=FULL（または等価のSEMANTICS）では、OCIRef変数を使用できません。
回避策は、OCIRef変数を含むPro*C/C++プログラム・モジュールには、常にSQLCHECK=SYNTAXを使用することです。そのためには、Pro*C/C++アプリケーション・プログラムを複数の.pcファイルにモジュール化することが必要になる場合があります。これにより、OCIRef変数を伴う.pcファイルには、埋込みPL/SQLブロック（SQLCHECK=FULLオプションを使用したプリコンパイルが必要）は含まれなくなります。
*5) リリース8.1.6では各国語キャラクタのLOBも、オブジェクト型の属性の場合を除いてサポートされます。
*6) ユーザー定義名を持つデータ型は、Oracleの動的SQLメソッド4ではサポートされません。新規のANSI動的SQLインタフェースを使用してサポートされます。
*7) 表の別名に対するVALUE()関数を使用して型付きの表からADTインスタンス全体を選択する操作は、埋込みPL/SQL、またはPro*C/C++コマンドライン・オプションSQLCHECK=FULL（またはSEMANTICS）ではサポートされません。
*8) LOB型のADT属性は、埋込みPL/SQL内では操作できません。回避策は、OCIルーチンまたは埋込みSQL LOBインタフェースを使用して、ADTに埋め込まれたLOB属性を操作することです。
Pro*C/C++では、EXEC SQL TYPEディレクティブに型の名前として使用されているマクロは拡張されません。たとえば、どのバージョンのPro*C/C++でも、次のディレクティブはサポートされません。
#define text char
EXEC SQL TYPE text IS STRING(..);
textマクロは拡張されていません。このPro*C/C++の注意事項はマニュアルにも記載されています。ここで言及するのは、以前のOracleリリースでは、textという単語が前述のEXEC SQL TYPE文の動作を可能にするCのtypedefを使用して定義されていたためです。
Oracleバンドル・リリースでtextの定義がtypedefからマクロに変更された場合、前述のようなSQLディレクティブはプリコンパイルできなくなります。
SQLNumberPrecV6( )でsqlprct( )が置き換えられています。
SQLNumberPrecV7( )でsqlpr2t( )が置き換えられています。
接続プール・オプション（Bug#2436580およびBug#2454956）
配列のSELECTおよびFETCHの実行時には、常にインジケータ配列が使用されます。これにより、関連する出力ホスト配列にNULLがあるかどうかをテストできます。DBMS=V7またはDBMS=v8の場合は、インジケータ配列に関連付けられていないホスト配列にNULLの列値をSELECTまたはFETCHすると、Oracleは処理を停止し、sqlerrd[ 2]が処理済の行数に設定されてエラー・メッセージが発行されます。また、SELECTまたはFETCHを実行した場合にNULLが使用されていることが原因でORA-24347などの警告が戻される場合、およびどの列にもインジケータ配列がない場合、Oracleは処理を停止します。
amountパラメータは、最大ロード量を示します。指定した量がロードされる前にソースBFILEの終わりに達すると、操作は終了してエラーORA-22993が戻されます。
同様に、REF変数（CのOCIRef型）とLOBロケータ（CのOCIBlobLocator型、OCIClobLocator型）に対する複数行の配列操作では、ホスト配列が適切なCの型のポインタである必要があります。たとえば、Pro*C/C++プログラムでは、この種の配列の有効な宣言は次のようになります。
OCIRef *ref_array[..];
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
LTYPE=SHORTオプション値を設定すると、.lisファイルの生成には、プログラム全体がリストされる公開形式ではなく詳細形式が使用されます。
|
 Copyright © 2001, 2004, Oracle Corporation All rights reserved |
|