標準の COBOL ストアド プロシージャのパラメーター (引数) は、COBOL データ型を使用します。SQL CLR ストアド プロシージャのパラメーターは、.NET データ型を使用します。COBOL ストアド プロシージャを SQL CLR 環境で正常に実行するためには、ストアド プロシージャが呼び出されるときの入力パラメーターと、呼び出し元のアプリケーションに戻るときの出力パラメーターの両方で、.NET データ型が使用されている必要があります。Enterprise Developer に COBOL または .NET のどちらのデータ型パラメーターを使用する COBOL ストアド プロシージャを提供するかを選択できます。どちらの方法を選択するかは、いくつかの要因によって左右されます。ここでは、最適な方法を決定するための考慮事項について説明します。
.NET データ型パラメーターを使用する COBOL ストアド プロシージャ
.NET データ型パラメーターを使用する COBOL ストアド プロシージャを提供する方法が適切かどうかは、使用する COBOL アプリケーションによって決まります。
- メリット
-
- 新しいストアド プロシージャを作成する場合、OpenESQL アシスタントを使用して、.NET データ型パラメーターを含むコードを自動的に生成できます。この方法では、OpenESQL アシスタントからストアド プロシージャを生成して、その成果物を既存の SQL CLR オブジェクトとして Enterprise Developer プロジェクトに追加します。詳細については、本マニュアルの「Using OpenESQL Assistant」セクションのサブトピック「Stored Procedures」を参照してください。
注：必ずしもメリットともデメリットとも言えませんが、
Enterprise Developer のエディターを使用して新しい SQL CLR オブジェクトのコードを手動で記述することもできます。手動で記述したコードを含む新しいファイルを
Enterprise Developer プロジェクトの一部として作成します。データ型パラメーターのコードを決定する以外に事前の準備は必要ありません。詳細については、「
SQL CLR 統合プロセス」を参照してください。
- SPD ファイルやラッパー プログラムを使用しなくても COBOL アプリケーションで COBOL ストアド プロシージャを正常に実行できます。
- デメリット
-
- COBOL データ型パラメーターを使用する COBOL ストアド プロシージャが既にある場合は、そのコードを手動で編集して .NET に変更する必要があります。
COBOL データ型パラメーターを使用する COBOL ストアド プロシージャ
COBOL データ型パラメーターを使用する COBOL ストアド プロシージャを提供する方法が適切かどうかも、使用する COBOL アプリケーションによって決まります。
- メリット
-
- 既に COBOL ストアド プロシージャがあり、それらを SQL Server に移行する必要がある場合は、この方法が便利です。この場合、既存のコードをそのまま使用できます。
注：必ずしもメリットともデメリットとも言えませんが、
Enterprise Developer のエディターを使用して新しい SQL CLR オブジェクトのコードを手動で記述することもできます。手動で記述したコードを含む新しいファイルを
Enterprise Developer プロジェクトの一部として作成します。データ型パラメーターのコードを決定する以外に事前の準備は必要ありません。詳細については、「
SQL CLR 統合プロセス」を参照してください。
- ストアド プロシージャ定義 (SPD) ファイルを渡すと、Enterprise Developer により、生成された COBOL ラッパー プログラムを使用して COBOL から .NET への変換が行われます。詳細については、「COBOL ラッパー プログラム」を参照してください。
- SPD ファイル内でパラメーターを定義することにより、COBOL グループ変数名を渡すことができます。詳細については、「ストアド プロシージャ定義 (SPD) ファイル」を参照してください。
- デメリット
-
- この方法では、SPD ファイルを作成したり、ストアド プロシージャを COBOL ラッパー プログラムでラップしたりする、追加のステップが必要になります。詳細については、「COBOL ラッパー プログラム」および「ストアド プロシージャ定義 (SPD) ファイル」を参照してください。