9.31 DEFINE_DB_SERVER

9.31 DEFINE_DB_SERVER

Þ 注：組 み込み関数の規則

このデータベースを使用するために特にリダイレクトされたファイルで使用するデータベースの詳細を定義します。

この定義の主な目的は、外部ファイルおよび他のデータベース内のSQLビューをサポートすることです。外部ファイルおよびSQLビューは、ファイル制御メ ニューの外部ファイルのロードを使用してLANSAにロードされます。

これは、異なる区画または外部データベースにあるLANSAユーザー・ファイルにアクセスするために使用することもできます。これらのファイル定義は、外 部のデータベースのリポジトリから現在のリポジトリにエクスポートする必要があります。外部リポジトリでファイル定義を変更した場合は、そのつど、現在の リポジトリに再インポートしてOAMを再作成する必要があります。

定義の詳細は、永続的なものではなく、LANSA環境がアクティブな間だけ存続します。

データベースを定義するのにかかる時間は、ほんのわずかです。

注1：こ のBIFは、DEFINE_OTHER_SERVERと同様の目的で使用しますが、OAMをローカルのPC上に常駐させたまま、データベースのI/Oを使 用してサーバーにアクセスする点だけが異なります。「デー タベース接続」を参照してください。

注2：こ のBIFでは、ローカルでデータベース接続を確立する必要があります。接続しないとエラーが返されます。

各製品の対応

引数

戻り値

技術上の注記

·         デー タベース識別子は、32ビットのODBC Administratorで定義された有効なODBCデータベース名である必要があります。通常は、外部ファイルをLANSAにロードする際に使用した ODBCデータベースと同じ名前を使用します。

·         サー バー定義および接続のロジックは、多数のRDMLファンクションに分散させるのではなく、1つのファンクションにのみコーディングすることを強くお勧めし ます。このようにすることで、将来サーバーに対して加えられる変更からアプリケーションを保護することができます。

·         SSN 値は、メッセージにしばしば表示される場合があるため、エンド・ユーザーにとって意味のある名前にすることをお勧めします(CHICAGO、 BOSTON、CHARLIE1など)。

·         SSN 名は、英語のアルファベット(大文字のAからZまで)で始まる固有の名前である必要があります。

·         サー バーが接続されていない時は、繰り返し再定義することができます。現在接続されているサーバーを再定義しようとすると、致命的なエラーが発生します。

·         デ フォルトでは、外部ファイルのロード時と同じ接続パラメータが使用されます。

·         接 続パラメータのオーバーライドは、このデータベースへの接続時に使用するパラメータを増加および置換するために使用することができます。既存のパラメータ は、パラメータの原則に従ってパラメータ上でのみ置換されます。このため、すでに存在しているパラメータは、オーバーライドのパラメータに指定されること はなく、そのまま存続します。

·         CONNECT_SERVER のBIFを使用してこのデータベースを接続する必要がある場合、すべての接続パラメータを、接続パラメータのオーバーライドとして指定する必要があり、こ のように指定しないと、ODBCからパラメータが欠落しているというプロンプトが出されます(注：DSN=、FILEDSN=、DRIVER=のODBC 接続パラメータは不要のため、無視されます)。また、オーバーライドするデータベース・タイプも指定する必要があります。これは、デフォルトのデータベー ス・タイプがOAMに保持されますが、CONNECT_SERVERのBIF使用時にはこのOAMが認識されていないためです。

·         ファ ンクションまたはコンポーネントで外部ファイルを使用する場合に、CONNECT_FILEで別のサーバーまたはデータベースに接続していない場合は、デ フォルトのデータベースが使用されます。データベースがこのBIFで定義されているかがシステムで検査されます。定義されている場合は、自動接続の前に接 続パラメータのオーバーライドが適用されます。

·         LANSA ファイルをこのデータベースに接続する必要がある場合でAUTO_RRNを使用していないときは、RRNパスの指定は必須です。

·         テー ブル定義がODBC Oracleを使用してLANSAにロードされると、Linuxサーバー内の外部ファイルをサポートした今後の使用のためにデータベース・タイプが提供さ れますが、実行ではネイティブのOracleが使用されます。これを使用して1つのODBCデータベース・タイプから別のデータベース・タイプに変更する と、OAMの実行時に致命的なエラーが発生します。つまり、このBIFで指定するデータベース・タイプは、特殊なOracle使用時を除き、OAMのデー タベース・タイプと一致させる必要があります。

·         こ の組み込み関数を使用して定義された詳細は、永続的なものではありません。X_RUNコマンドが終了すると消滅します。ユーザー独自のSQLベースのテー ブルを定義して、サーバー詳細を保持したり、テーブルを実際に読み込んでこの組み込み関数に渡される値を取得することができます。

·         接 続パラメータのオーバーライドによってユーザーが接続情報を求められた場合(データベース・ログインやパスワードなど)、このBIFで定義されている接続 パラメータのオーバーライドを、データベースの接続で使用された実際の接続文字列に更新することができます。この機能は、このSSNに新しくODBC接続 するたびに、または、DISCONNECT_SERVERを使用した後で、CONNECT_SERVERを使用した場合などに、ユーザーにプロンプトが表 示されるのを防ぐためのものです(例えば、SQLサーバーでは、接続の更新と複数の接続読み取りが必要です)。DISCONNECT_SERVERを実行 してユーザーに強制的に接続の詳細情報を入力するようにする場合は、このBIFを再度呼び出して当初の値を置き換える必要があります。

·         こ れらの機能で十分に経験を積んでから、組織で使用する特定のサーバー・アーキテクチャを設計するようにしてください。サーバー・アーキテクチャは、以下の ような特徴が必要です。

·         組 織の要件を満たしている

·         手 早く容易に変更できる

·         拡 張可能である

·         大 規模な設計あるいは開発プロジェクトに着手する前に、これを実行してください。

例

次に、データベースMYDATABASEに接続するCHICAGOという名前のデータベース・サーバーを定義して、ユーザーIDとパスワードをnullに 設定したために、ODBCからユーザーIDおよびパスワードを入力するように促すプロンプトが表示される例を示します。

USE BUILTIN(DEFINE_DB_SERVER) WITH_ARGS(CHICAGO MYDATABASE "UID=;PWD=;") TO_GET(#RETCOD)
 

この場合、MYDATABASEと関連付けられているファイルが最初に使用されると接続が確立されます。

エラー処理に関する注意事項

複雑なエラー処理スキームをご使用のアプリケーションに組み込むことは避けるよう、強くお勧めします。アプリケーションのすべてのレベルで、以下のような ごく単純なトラップを使用するようにしてください。

if (#retcode *ne OK)

abort msgtxt('Failed to .............................') 

endif

標準的なエラー処理を行うように、生成されるすべてのアプリケーションに組み入れて、問題に対処するようにしてください。ユーザー定義のエラー処理ロジッ クが非常に複雑になったために全RDMLコードの40から50%を占有するようなケースもあります(アプリケーションには何のメリットもありません)。こ のような事態に陥らないようにしてください。