ソース・テーブルがメモリ常駐の LANSA テーブルとフィールドに変換された後、プレビュー・ページが表示されます。
このプレビュー・ページにより、LANSA リポジトリにコミットする前に結果を確認できます。
変換処理について
最も簡単な形では、変換処理では、テーブルと列はソース・オブジェクトと同一の名前で LANSA テーブルとフィールドに転換されます。
各テーブルは LANSA テーブルとなり、各列は LANSA フィールドになります。すべての列は LANSA データ・タイプに変換されます。プレビュー・ページに確定前のフィールドとソースの詳細が括弧内に表示されます。
データベースは複数のテーブル内に同じ列名を持つ場合が多くあり、ほとんどの場合、列の定義もすべてのテーブルで同じです。その結果、複数の作成されたテーブルすべてに対し作成されるのは 1 つのフィールドになります。
ただし、異なるテーブルで定義が異なる場合は、変換処理では異なる列の要求に従い複数のフィールドを作成するようになります。
列はそのデータ・タイプ、長さ、小数点の位置、NULL 値の割当てのサポート有無をベースに評価されます。
LANSA 命名ポリシー
LANSA の内部命名規則により、LANSA リポジトリのオブジェクトは同じ名前を持てないようになっています。つまり、名前が重複した場合、2 つ目および後続のオブジェクトの名前は一意になるよう変更されます。
テーブルのリロード
サードパーティのテーブルがなんらかの理由で変更された場合は、定義をリロードする必要があります。これを行わない場合、既存のこのテーブルに対するオブジェクト・アクセス・モジュールが定義と一致しません。これにより、変更された内容によりますが、データ破損や実行時エラーが発生する可能性があります。
最初のロードと同じく、LANSA は、生成されたテーブルとフィールドが確実にソース定義に忠実に則っているようにします。
ただし、定義のリロードは複雑な問題を引き起こす可能性もあります。ほとんどの場合予測通りの結果となりますが、ユーザーによる直接入力の内容によって、ベストなアクションが変わるケースもあります。
ロードとリロードの問題点
名前の重複や列定義の変更の場合、LANSA はベストな結果になるよう最善を尽くします。
ロードで何が起きたかを理解してもらうため、変換処理で何かが変更された場合、アイテムの下にメッセージが表示されます。さらに、ステータスの列には追加情報が示されます。
新規フィールドまたは既存の更新?
ほとんどの場合、列の処理方法は比較的簡単に決定できます。
新規の名前
列と同じ名前のフィールドが存在しない場合、新規フィールドが作成されます。今後の参照に備え、ソース・テーブルはフィールドに対して記録されます。
これらのフィールドのステータスは新規となります。
既存の名前
列と同じ名前のフィールドが存在する場合、フィールドのソース (つまり、この派生元のテーブル) とロードされるテーブルが比較されます。テーブルが一致すれば、このフィールドは列の属性とともに更新されます。
これらのフィールドのステータスは変更となります。
既存の名前と部分リロード
名前の一致が検知され、列属性が変更されていた場合は、両方のソース・テーブルが評価されます。これが異なる場合、変換処理では今後の作業方法を決定することはできません。フィールドは複数の LANSA テーブルで利用されていますが、すべてのソース・テーブルの情報が入手できるわけではありません。
これらのフィールドのステータスは部分リロードとなります。
ドロップダウンが提供され、フィールドを更新するか、新規フィールドを作成するか、変更を無視するかを決定することができます。
既存の名前と不一致
複数のテーブルをロードする時、各ソース・テーブルから異なる属性を持つ同じ名前の列がある可能性があり、これらが LANSA フィールドに一致しない場合があります。このような状況の場合、変換処理では解決策として新たにフィールドを作成することしかできません。
この状況は、ソース・テーブルの定義に問題があることを示唆しています。
これらのフィールドのステータスは不一致となり、ソース・テーブルにも不一致のフラグが立てられます。
この不一致の原因を探るためにも、ソース・テーブルと列を調査することを強くお勧めします。
終了
[終了] ボタンがクリックされると、フィールドおよびテーブルが作成されます。
この処理はロードされるテーブルや列の量によって、数分かかる場合もあります。
