使用者の手引き

分散環境でのプログラミング

DB2 コネクトにより、アプリケーション・プログラムは、 System/390 サーバーと AS/400 サーバー上にある DB2 データベース内のデータにアクセスできます。 たとえば、Windows の下で実行されているアプリケーションは DB2 ユニバーサル・データベース (OS/390 版) データベース内のデータにアクセスできます。 新規のアプリケーションを作成することもできますし、 既存のアプリケーションをホストまたは AS/400 環境で実行できるように修正することもできます。 ある 1 つの環境でアプリケーションを開発し、それを別の環境に移植することもできます。

DB2 コネクトを使用すれば、DB2 ユニバーサル・データベース (OS/390 版) のようなホスト・データベース製品で以下の API が利用できるようになります。 ただし使用できるのは、その項目がホスト・データベース製品によりサポートされている場合に限られます。

SQL ステートメントの中には、関係データベース製品によって相違のあるものもあります。 使われる SQL ステートメントは以下のように分類できます。

はじめの 2 つの類別の SQL ステートメントは可搬性が高いですが、 3 番目の類別の SQL ステートメントはまず変更を行うことが必要な場合があります。 一般的に、データ定義言語 (DDL) での SQL ステートメントは、 データ操作言語 (DML) での SQL ステートメントほど可搬性が高くありません。

DB2 ユニバーサル・データベースではサポートされていない SQL ステ ートメントでも DB2 コネクトには受け入れられるものがあります。 DB2 コネクトはこれらのステートメントをホストまたは AS/400 サーバーに渡します。 最大列長のような別のプラットフォームの制限に関する情報は、 SQL 解説書 を参照してください。

CICS アプリケーションを OS/390 または VSE から他の CICS 製品 (たとえば CICS (AIX 版) ) の下で実行するよう移植する場合には、 DB2 コネクトを使用して OS/390 または VSE のデータベースにアクセスすることもできます。 詳細については、 CICS/6000 適用業務プログラミングの手引き および CICS カストマイゼーションおよび操作 を参照してください。

ホストまたは AS/400 環境でプログラミングを行う場合は、 以下に挙げる要因に特に注意してください。

データ定義言語 (DDL) の使用

異なるシステムでは記憶域の扱われ方が異なるので、 DDL ステートメントは IBM データベース製品により異なります。 ホストまたは AS/400 サーバー・システムでは、 データベースの設計と CREATE TABLE ステートメントの発行の間にいくつかのステップがあり得ます。 たとえば、一連のステートメントによって、論理オブジェクトの設計を、 それらのオブジェクトの記憶域内での物理的表現へと変換する場合があります。

ホストまたは AS/400 サーバー・データベースへのプリコンパイルを行うさいに、 プリコンパイラーはそのような多くの DDL ステートメントをホストまたは AS/400 サーバーに渡します。 その同じステートメントは、 アプリケーションが実行されているシステム上のデータベースに対してはプリコンパイルを行いません。 たとえば、OS/2 アプリケーションにおいて、 CREATE STORGROUP ステートメントは DB2 ユニバーサル・データベース (OS/390 版) データベースに対しては正常にプリコンパイルされますが、 DB2 (OS/2 版) データベースに対しては正常にプリコンパイルされません。

データ操作言語 (DML) の使用

一般的に、DML ステートメントには高い可搬性があります。 SELECT、 INSERT、UPDATE、および DELETE ステートメントなどは、IBM 関係データベース製品の間で類似しています。 ほとんどのアプリケーションは主に DML SQL ステートメントを使用しています。 それらは DB2 コネクト・プログラムによりサポートされています。

数値データ・タイプ

数値データが DB2 ユニバーサル・データベース に転送されると、データ・タイプが変わることがあります。 (DB2 ユニバーサル・データベース (AS/400 版) によってサポートされる) 数値およびゾーン 10 進の SQLTYPE は、 固定 (パック) 10 進の SQLTYPE に変換されます。

混合バイト・データ

混合バイト・データは、拡張 UNIX 文字セット (EUC) の文字、 2 バイト文字セット (DBCS) の文字および 1 バイト文字セット (SBCS) の文字が同じ列の中で構成されています。 データを EBCDIC で保管するシステム (OS/390、 OS/400、VSE および VM) では、 2 バイト・データの始まりと終わりはシフトアウト (SO) 文字およびシフトイン (SI) 文字で印付けられます。 データを ASCII で保管するシステム (OS/2 および UNIX など) では、 シフトイン文字およびシフトアウト文字は必須ではありません。

アプリケーションで混合データを ASCII システムから EBCDIC システムへ転送する場合は、 シフト文字のための十分な余地を確保するようにしてください。 SBCS データから DBCS データへ切り換わるたびに、 データの長さにそれぞれ 2 バイトを追加してください。 さらに可搬性を良くするためには、 混合データを使用するアプリケーションには可変長ストリングを使用してください。

長フィールド

長フィールド (長さが 254 文字を超えるストリング) は、システムによって扱い方が異なります。 ホストまたは AS/400 サーバーは、 長フィールド用のスカラー関数のサブセットだけをサポートしています。 たとえば、DB2 ユニバーサル・データベース (OS/390 版) では、 長フィールドに合わせて LENGTH および SUBSTR 関数だけが許されます。 また、ホストまたは AS/400 サーバーでは、 ある種の SQL ステートメントには別の取り扱いが必要になります。 たとえば DB2 (VSE および VM 版) では、INSERT ステートメントを用いる場合、ホスト変数、 SQLDA、またはヌル値だけを使用することが必要です。

ラージ・オブジェクト (LOB) データ・タイプ

LOB データ・タイプは DB2 コネクトでサポートされています。

ユーザー定義タイプ (UDT)

DB2 コネクトではユーザー定義の具象タイプだけがサポートされています。 抽象データ・タイプはサポートされていません。

ROWID データ・タイプ

ROWID データ・タイプは、DB2 コネクトではビット・データ用の VARCHAR として処理されます。

64 ビット整数 (BIGINT) データ・タイプ

DB2 コネクトでは 8 バイト (64 ビット) 整数がサポートされています。 BIGINT 整数データ・タイプは、データ精度を保ちながら大規模データベースのカー ディナリティーをサポートするときに使用します。

データ制御言語 (DCL) の使用

各 IBM 関係データベース管理システムでは、 GRANT および REVOKE SQL ステートメントにいろいろなレベルの区分が用意されています。 各データベース管理システムで使用するのに適した SQL ステートメントを確認するために、 製品特定の出版物を調べてください。

接続および切断

DB2 は、パラメーターを指定していない CONNECT を、 CONNECT ステートメントの CONNECT TO および CONNECT RESET バージョンと同様にサポートしています。 アプリケーションが CONNECT TO ステートメントを先に明示的に実行せずに SQL ステートメントを呼び出した場合、 省略時アプリケーション・サーバー (それが存在する場合) への暗黙 接続が実行されます。

データベースに接続するときには、 関係データベース管理システムを識別するための情報が SQLCA の SQLERRP フィールドに戻されます。 アプリケーション・サーバーが IBM 関係データベースの場合、 SQLERRP の先頭の 3 バイトは以下のいずれかを含みます。

DSN
DB2 ユニバーサル・データベース (OS/390 版)

ARI
DB2 (VSE および VM 版)

QSQ
DB2 ユニバーサル・データベース (AS/400 版)

SQL
DB2 ユニバーサル・データベース

DB2 コネクトを使用しているときに CONNECT TO または null CONNECT ステートメントを発行した場合、 SQLCA の SQLERRMC フィールド内には国別コードまたは領域トークンがブランクとして戻されます。 アプリケーション・サーバーの CCSID はコード・ページまたはコード・セット・トークンに戻されます。

明示的に切断を行うには、CONNECT RESET ステートメント (タイプ 1 接続の場合)、 RELEASE および COMMIT ステートメント (タイプ 2 接続の場合)、 または DISCONNECT ステートメント (どちらの接続タイプでも可、 ただし TP モニター環境では不可) を使用します。

接続が明示的に切断されずにアプリケーションが正常終了した場合、 DB2 コネクトは結果のデータを暗黙のうちにコミットします。
注:アプリケーションが正常終了したのに、 エラーを示す SQLCODE を依然として受け取る場合があります。 この場合、DB2 コネクトはデータをコミットします。 データのコミットを行いたくない場合は、ROLLBACK コマンドを発行してください。

FORCE コマンドは、選択したユーザーまたはすべてのユーザーをデータベースから切断します。 これはホストまたは AS/400 サーバー・データベースにもサポートされるので、 ユーザーは DB2 コネクト・ワークステーションの強制切断を行うことができます。

プリコンパイル

各種の IBM 関係データベース・システムの間で、 プリコンパイルに関していくつかの相違点があります。 DB2 ユニバーサル・データベース用のプリコンパイラーは、 以下の点でホストまたは AS/400 サーバーのプリコンパイラーと異なります。

ブロック化

DB2 コネクトは、 DB2 データベース・マネージャーのブロック化バインド・オプションをサポートします。

UNAMBIG
確定カーソルだけがブロック化されます (省略時値)。

ALL
未確定カーソルがブロック化されます。

NO
カーソルはブロック化されません。

DB2 コネクト・プログラムは、 DB2 データベース・マネージャー構成ファイルで定義された ブロック・サイズを RQRIOBLK フィールドに使用します。 DB2 コネクトの現行バージョンでは、 ブロック・サイズを最大 32 767 までサポートします。 それより大きな値が DB2 データベース・マネージャー構成ファイルで指定される場合、 DB2 コネクトは 32 767 値を使用しますが、 DB2 データベース・マネージャーをリセットしません。 ブロック化は、動的 SQL と静的 SQL で同じブロック・サイズが使用され、 同じ方法で処理されます。
注:ほとんどのホストまたは AS/400 サーバー・システムは動的カーソルを未確定とみなしますが、 DB2 ユニバーサル・データベース・システムは一部の動的カーソルを確定カーソルとみなします。 混乱を避けるため、DB2 コネクトでは BLOCKING ALL を指定することができます。

管理 API 解説書 およびコマンド解説書 でリストしているように、CLP、コントロール・センター、 または API を使用して DB2 データベース・マネージャー構成ファイルにおいてブロック・サイズを指定してください。

パッケージ属性

パッケージには以下の属性があります。

集合 ID
パッケージの ID。 PREP コマンドに指定することができます。

所有者
パッケージ所有者の許可 ID。 PREP コマンドまたは BIND コマンドに指定することができます。

作成者
パッケージをバインドするユーザー名。

修飾子
パッケージ内のオブジェクトの暗黙修飾子。 PREP コマンドまたは BIND コマンドに指定することができます。

それぞれのホストまたは AS/400 サーバー・システムで、これらの属性の使用に関する制限があります。

DB2 ユニバーサル・データベース (OS/390 版)
4 つの属性すべてが別々でもかまいません。 異なる修飾子を使用するには、特別な管理特権が必要になります。 これらの属性の使用条件について詳しくは、 DB2 ユニバーサル・データベース (OS/390 版) のコマンド解説書 を参照してください。

DB2 (VSE および VM 版)
すべての属性は同一でなければなりません。 USER1 がバインド・ファイルを作成し (PREP 使用)、 USER2 が実際のバインドを実行する場合、USER2 は、 USER1 に代わってバインドを実行するために DBA 権限が必要になります。 USER1 のユーザー名だけが属性に使用されます。

DB2 ユニバーサル・データベース (AS/400 版)
修飾子は集合名を示します。 修飾子と所有権との関連は、オブジェクトにおける特権の授与や取り消しに影響を与えます。 ユーザー名が集合 ID によって修飾されない限り、ログオンされるユーザー名が作成者および所有者になります。 ユーザー名が集合 ID によって修飾されているときは、集合 ID が所有者になります。 集合 ID は、修飾子として使用される前から存在していなければなりません。

DB2 ユニバーサル・データベース
4 つの属性すべてが別々でもかまいません。 別の所有者を使用するには、管理権限が必要で、 スキーマ (既存の場合) に対する CREATEIN 特権がバインダーになければなりません。

注:DB2 コネクトは、 DB2 ユニバーサル・データベース (OS/390 版) および DB2 ユニバーサル・データベースで SET CURRENT PACKAGESET コマンドをサポートしています。

C のヌル文字で終了するストリング

CNULREQD バインド・オプションは、 LANGLEVEL オプションを使用して指定したヌル文字で終了するストリングの処理をオーバーライドします。

LANGLEVEL オプションを MIA または SAA1 に設定した場合にヌル文字で終了するストリングがどのように処理されるかについては、 アプリケーション開発の手引き を参照してください。

省略時には、CNULREQD は YES に設定されます。 こうすることによって、ヌル文字で終了するストリングは MIA 標準に従って解釈されます。 DB2 ユニバーサル・データベース (OS/390 版) サーバーに接続している場合には、CNULREQD を YES に設定するよう強くお勧めします。 CNULREQD オプションを NO に設定して、 (ヌル文字で終了するストリングに関係して) SAA1 標準にコード化されたアプリケーションをバインドする必要があります。 そうしなければ、ヌル文字で終了するストリングを SAA1 に設定した LANGLEVEL を使用して作成しても、 MIA 標準で解釈される場合があります。

スタンドアロン SQLCODE および SQLSTATE

ISO/ANS SQL92 で定義されているスタンドアロン SQLCODE および SQLSTATE 変数は、 LANGLEVEL SQL92E プリコンパイル・オプションを介してサポートされます。 SQL0020W 警告がプリコンパイル時刻に発行される場合は、 LANGLEVEL がサポートされていないことを示しています。 この警告は LANGLEVEL SQL92E のサブセットである コマンド解説書 で LANGLEVEL MIA の下にリストされている機能にのみ適用されます。

分類順序の定義

EBCDIC と ASCII の差は、種々のデータベース製品間の分類順序の差を引き起こし、 ORDER BY と GROUP BY 句にも影響を及ぼします。 それらの差を最小限にとどめる方法の 1 つは、 EBCDIC 分類順序に模倣するユーザー定義の照合順序を作成することです。 照合順序の指定は、新規データベースを作成するときだけ行うことができます。 詳細については、 アプリケーション開発の手引き管理 API 解説書、 およびコマンド解説書 を参照してください。
注:データベース表は ASCII 形式の DB2 ユニバーサル・データベース (OS/390 版) に保管できるようになりました。 このことは DB2 コネクトと DB2 ユニバーサル・データベース (OS/390 版) 間のより速いデータの交換を可能にします。また、これによりデータを変換 したり並べかえるのに使用するフィールド手順は必要なくなります。

参照保全の管理

システムが異なると参照制約の扱い方も異なります。

DB2 ユニバーサル・データベース (OS/390 版)
外部キーは基本キーを使用して作成しますので、基本キーに関する索引を先に作成しておく必要があります。 表はそれ自身を参照することができます。

DB2 (VSE および VM 版)
外部キー用の索引は自動的に作成されます。 表はそれ自身を参照することができません。

DB2 ユニバーサル・データベース (AS/400 版)
外部キー用の索引は自動的に作成されます。 表はそれ自身を参照することができます。

DB2 ユニバーサル・データベース
DB2 ユニバーサル・データベースのデータベースの場合、固有制約 (基本キーを含む) には 1 つの索引が自動的に作成されます。 表はそれ自身を参照することができます。

他の規則については、関係する連鎖のレベルにより変化します。

ロック

データベース・サーバーのロッキング方法は、アプリケーションにまで影響することがあります。 たとえば、行レベルのロックで設計されたアプリケーション、およびカーソル固定の分離レベルは、 ページ・レベルのロックを実行するシステムに直接移送することはできません。 これらの潜在的な差のゆえに、アプリケーションを調整する必要のある場合があります。

DB2 ユニバーサル・データベース (OS/390 版) および DB2 ユニバーサル・データベース製品には、ロックをタイムアウトにして待機中のアプリケーションにエラー戻りコードを送る機能があります。

SQLCODE および SQLSTATE に関する相違点

異なる IBM 関係データベース製品は、 類似のエラーについて必ずしも同じ SQLCODE を発行するものではありません。 この問題には、2 とおりの対処の仕方があります。

システム・カタログの使用

システム・カタログは、IBM データベース製品により異なります。 視点を使用することにより、多くの相違点をマスクすることができます。 詳細については、使用しているデータベース・サーバーの資料を参照してください。

CLI にあるカタログ機能は、同じ API にサポートされることにより、この問題を克服し、 DB2 ファミリー全体のカタログ照会を設定していきます。

検索割り当てにおける数値変換オーバーフロー

検索割り当てでのオーバーフローは、 IBM 関係データベース製品によって異なった処理がなされる場合があります。 たとえば、DB2 ユニバーサル・データベース (OS/390 版) および DB2 ユニバーサル・データベースから整数のホスト変数の中に浮動列を取り入れることを考慮してください。 浮動値を整数値に変換する際に、変換オーバーフロー (桁あふれ) が生じる場合があります。 省略時解釈では DB2 ユニバーサル・データベース (OS/390 版) は、 アプリケーションに警告 SQLCODE およびヌル値を戻します。一方、DB2 ユニバーサル・データベースは変換オーバーフロー・エラーを戻します。適正なサイズのホスト変数を取り出すことにより、 検索割り当てにおける数値変換オーバーフローを回避するようお勧めします。

分離レベル

アプリケーションを prep またはバインドするとき、 DB2 コネクトは以下の分離レベルを受け入れます。

RR
反復可能読み取り

RS
読み取り固定

CS
カーソル固定

UR
非コミット読み取り

NC
コミットなし

分離レベルは保護の大きい順にリストしてあります。 指定した分離レベルをホストまたは AS/400 サーバーがサポートしていない場合、 その次に高いサポートされているレベルが使用されます。

表 2 は、各ホストまたは AS/400 アプリケーション・サーバーにおけるそれぞれの分離レベルの結果を示しています。

表 2. 分離レベル
DB2 コネクト DB2 ユニバーサル・データベース (OS/390 版) DB2 (VSE および VM 版) DB2 ユニバーサル・データベース (AS/400 版) DB2 ユニバーサル・データベース
RR RR RR 注 1 RR
RS 注 2 RR COMMIT(*ALL) RS
CS CS CS COMMIT(*CS) CS
UR 注 3 CS COMMIT(*CHG) UR
NC 注 4 注 5 COMMIT(*NONE) UR

注:

  1. DB2 ユニバーサル・データベース (AS/400 版) 用には RR に一致する同 等の COMMIT オプションはありません。DB2 ユニバーサル・データベース (AS/400 版) 用は表全体をロックすることにより RR をサポートします。

  2. バージョン 3.1 では RR、 APAR PN75407 付きバージョン 4.1 およびバージョン 5.1 では RS になります。

  3. バージョン 3.1 では CS、 バージョン 4.1 または 5.1 では UR になります。

  4. バージョン 3.1 では CS、 APAR PN60988 付きバージョン 4.1 およびバージョン 5.1 では UR になります。

  5. DB2 (VSE および VM 版) では分離レベル NC はサポートされてい ませ ん。

DB2 ユニバーサル・データベース (AS/400 版) では、分離レベルが UR でブロック化が ALL にセットされていてアプリケーションがバインドされているならば、 もしくは分離レベルが NC にセットされているならば、ジャーナルされていない表にアクセスすることができます。

ストアード・プロシージャー

ストアード・プロシージャー・ビルダー

DB2 ストアード・プロシージャー・ビルダーは、ストアード・プロシージャーの作成、インストール、 テストのための使いやすい開発環境です。 これを使うことで、DB2 サーバー上におけるストアード・プロシージャーの登録、 構築、インストールといった細かい作業に注意を奪われることなく、 ストアード・プロシージャーのロジックを作成することに集中できます。 さらに、ストアード・プロシージャー・ビルダーを使えば、 あるオペレーティング・システム上でストアード・プロシージャーを開発し、 別のサーバー・オペレーティング・システム上でそれらを構築することも可能になります。

ストアード・プロシージャー・ビルダーはグラフィカルなアプリケーションであり、 迅速な開発をサポートしています。 ストアード・プロシージャー・ビルダーを使えば、以下の作業を行うことができます。

ストアード・プロシージャー・ビルダーは「DB2 ユニバーサル・データベース (DB2 Universal Database)」プログラム・グループから単独のアプリケーションとして起動できます。 あるいは、以下のいずれかの開発用アプリケーションから起動することも可能です。

さらに、DB2 (OS/390 版) のコントロール・センターからストアード・プロシージャー・ビルダーを起動することもできます。 ストアード・プロシージャー・ビルダーは単独のプロセスとして、 コントロール・センターの「ツール (Tools)」メニュー、ツールバー、 「ストアード・プロシージャー (Stored Procedure)」フォルダーなどから開始することが可能です。 また、「ストアード・プロシージャー・ビルダー・プロジェクト (Stored Procedure Builder Project)」ウィンドウからは、 DB2 (OS/390 版) サーバーに組み込まれた SQL ストアード・プロシージャーを 1 つ以上選択して、 コマンド行プロセッサー (CLP) 内で実行できる指定されたファイルへエクスポートできます。

ストアード・プロシージャー・ビルダーは作業結果を管理するのにプロジェクトを使用します。 それぞれのストアード・プロシージャー・ビルダー・プロジェクトには、 特定のデータベース (DB2 (OS/390 版) サーバーなど) への接続が保管されます。 また、フィルターを作成して各データベースごとにストアード・プロシージャーのサブセットを表示させることも可能です。 新規の、あるいは既存のストアード・プロシージャー・ビルダー・プロジェクトをオープンするときに、 ストアード・プロシージャーが名前、スキーマ、 言語、集合 ID (OS/390 のみ) に基づいて表示されるよう、 ストアード・プロシージャーにフィルターをかけることができます。

接続情報はストアード・プロシージャー・ビルダー・プロジェクトに保管されます。 そのため既存のプロジェクトをオープンすると、そのデータベースのユーザー ID とパスワードを入力するよう自動的に要求されます。 「SQL ストアード・プロシージャーの挿入 (Inserting SQL Stored Procedure)」ウィザードを使用すれば、 SQL ストアード・プロシージャーを DB2 (OS/390 版) サーバー上で構築できます。 DB2 (OS/390 版) サーバーに組み込まれた SQL ストアード・プロシージャーの場合、 コンパイル、プリリンク、リンク、バインド、 実行時、WLM 環境、外部セキュリティーといったオプションを具体的に設定できます。

さらに、その SQL ストアード・プロシージャーに関する SQL コスト情報を入手することもできます。 これには、その SQL ストアード・プロシージャーを実行しているスレッドの CPU 時間に関する情報やその他の DB2 コスト情報も含まれます。 特に、ラッチ / ロック競合の待ち時間、getpage の数、読み取り入出力の回数、 書き込み入出力の回数などに関するコスト情報を入手できます。

コスト情報を入手するにあたって、 ストアード・プロシージャー・ビルダーは DB2 (OS/390 版) サーバーに接続し、 SQL ステートメントを実行し、ストアード・プロシージャーを呼び出す (DSNWSPM) ことにより、 その SQL ストアード・プロシージャーが使った CPU 時間の量を調べます。

NOT ATOMIC 複合 SQL

複合 SQL では、 複数の SQL ステートメントを単一の実行可能ブロックとしてグループにまとめることができます。 このようにすればネットワーク・オーバーヘッドを減らすことができ、応答時間が改善されます。

DB2 コネクトは NOT ATOMIC 複合 SQL をサポートしています。 このことは、複合 SQL の処理はエラーが生じた後にも続けられることを意味します。 (DB2 コネクトではサポートされていない ATOMIC 複合 SQL を使用した場合、 エラーが生じたときにはその複合 SQL グループ全体がロールバックされます。)

ステートメントは、 アプリケーション・サーバーによって終了させられるまで実行し続けます。 一般的に言って、 複合 SQL ステートメントの実行が停止するのは重大エラーが発生した場合だけです。

NOT ATOMIC 複合 SQL は、サポートされているホストまたは AS/400 アプリケーション・サーバーすべてで使用することができます。

複数の SQL エラーが発生した場合、 最初から 7 番目までの失敗したステートメントの SQLSTATE が、 SQLCA の SQLERRMC フィールドに戻されます。 その際、複数のエラーが発生したことを示すメッセージも一緒に戻されます。 詳細については、SQL 解説書 を参照してください。

DB2 コネクトによる複数サイト更新

DB2 コネクトを使って、複数サイト更新 (2 フェーズ・コミットともいう) を実行することができます。 複数サイト更新とは、 単一の分散作業単位 (DUOW) 内で複数のデータベースを更新することです。 ユーザーがこの機能を使用するかどうかはいくつかの要因によって決まります。

DB2 コネクトがサポートするホストまたは AS/400 サーバー SQL ステートメント

以下に挙げるステートメントは、ホストまたは AS/400 サーバーでの処理用に正常にコンパイルできますが、 DB2 ユニバーサル・データベース・システムでの処理用には正常にコンパイルできません。

上記のステートメントは、コマンド行プロセッサーでもサポートされています。

以下に挙げるステートメントは、ホストまたは AS/400 サーバーでの処理用にサポートされていますが、 バインド・ファイルやパッケージに付加されることはなく、コマンド行プロセッサーによるサポートもありません。

プリコンパイラーは以下のことを仮定します。

DB2 コネクトが拒否するホストまたは AS/400 サーバー SQL ステートメント

以下の SQL ステートメントは、DB2 コネクトでもコマンド行プロセッサーでもサポートされていません。

DB2 (VSE および VM 版) により拡張された動的 SQL ステートメントは、 -104 および構文エラー SQLCODE で拒否されます。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]