現在地: LANSA テクニカル リファレンスガイド > 9. 組み込み関数 > 9.37 DEFINE_DB_SERVER

9.37 DEFINE_DB_SERVER

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

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

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

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

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

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

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

 

引数

番号

タイプ

必須/任意

記述

最小長

最大長

最小小数桁数

最大小数桁数

1

A

必須

SSN (サーバーの別名)。これは、今後のこのサーバーへのすべての参照でこのファンクションおよび他のRDMLファンクションが使用する名前です。

1

10

 

 

2

A

必須

データベース識別子

1

32

 

 

3

A

任意

接続パラメータのオーバーライド(ブランク可)

1

256

 

 

4

A

任意

RRN パスのオーバーライド(ブランク可)指定する場合は、パス区切り記号(MS Windowsの場合はバック・スラッシュ)で終了する必要があります。

1

256

 

 

5

A

任意

データベース・タイプのオーバーライド(ブランク可)。「X_DBMENV.DAT ファイル」に記載されている有効なデータベース・タイプを指定してください。

1

32

 

 

6

A

任意

ODBI:このデータベースのトランザクション・アイソレーション・レベルを指定して設定するためにオーバーライドします。0から4までの値またはブランクが指定可能です。0はデータベースのデフォルト設定であることを示します。ブランクは、ODBI=パラメータと同じであることを示します。詳細については、「ODBI=パラメータ」を参照してください。

1

1

 

 

7

A

任意

ODBA:このパラメータは廃止予定です。詳細については、「ODBA= パラメータ」を参照してください。

1

1

 

 

 

 

戻り値

番号

タイプ

必須/任意

記述

最小長

最大長

最小小数桁数

最大小数桁数

1

A

必須

戻りコード

OK:サーバーが定義された

ER:サーバーが未定義でエラー・メッセージが発行される

2

2

 

 

 

 

技術上の注記

次に、データベース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%を占有するようなケースもあります (アプリケーションには何のメリットもありません)。このような事態に陥らないようにしてください。