元となるデータベース列が Unicode としてデータベースに格納されている場合、LANSA は次のガイドラインに従って、自動的に適切なフィールドを作成、または再利用します。

  • フィールド定義がすでに存在し、属性が SUNI の Char または String が含まれる場合、Unicode データベース用に新規作成されるフィールドはすべて、属性が SUNI の Char、String または CLOB フィールドとして作成されます。

  • このルールの唯一の例外は、CCSID 1208 (UTF-8) の IBM i ネイティブ タイプ Alpha であり、常に Nchar または Nvarchar としてロードされます。

  • 新規のファイル、またはファイルに属性が SUNI の Char、String または CLOB フィールドがない場合、インポートで Unicode フィールドは Nchar または Nvarchar として作成されます。

SUNI フィールドを持つ外部ファイル

既存の外部ファイルに属性が SUNI のフィールドが含まれる場合、フィールドが Nchar や Nvarchar を使用するようにファイルを再ロードしたいと思うでしょう。そのために、属性が SUNI のすべての Char と String のフィールドをファイルから削除した後にファイルを再ロードする必要があります。

以下はこれを行う方法の例です。ここに示される方法は、自身の状況に合わせて変更してください。

変更のための準備

  1. ファイルおよび属性が SUNI のフィールドをチェックアウトします。
  2. ファイルのすべての SUNI フィールドのコピーとなる新規のフィールドを作成します。必要なければ、これらは後で削除することができます。
  3. SUNI フィールド、このフィールドを使用するすべてのオブジェクト、新しく作成されたコピーのフィールドのリストを新規に作成します。このリストを Excel に保存します。
  4. DISPLAY、REQUEST、POP_UP コマンドで SUNI フィールドを使用するすべての *WEBEVENT ファンクションをメモします。
  5. このフィールドを使用するオブジェクトをすべてチェックアウトします。
  6. ファイル定義を印刷します。
  7. SUNI フィールドをファイルから削除します。
  8. リポジトリから SUNI フィールドを削除します。

新規フィールドを作成するファイルを再ロード

  1. ファイルを再ロードします。これで、元の SUNI フィールドが Nchar または Nvarchar フィールドとして置き換えられているはずです。
  2. 新規フィールドの妥当性規則、トリガー、多言語の記述などを元のフィールドの内容で更新します。情報は事前に元のフィールドをコピーした時に保存されています。
  3. SUNI フィールドが *WEBEVENT ファンクションの DISPLAY、REQUEST、または POP_UP コマンドで使用されている場合、ここでは、引き続き SUNI フィールドを使用します。最も簡単な方法は、コピー・フィールドを取り出して、元の識別子にコピーし直した後、ファイルの仮想フィールドとして使うことです。Unicode フィールド・タイプが SUNI フィールドに割り当てらた場合、すべてのデータが現在のコードページで認識されていない限り、データ損失の恐れがあることを忘れないでください。

変換の終了

  1. 新規フィールドが古いフィールドと同じ識別子を使用するという保証はありません。識別子が異なっており、このフィールドがファイル定義以外で利用される場合、次の 2 つのオプションがあります。
    • 事前に作成した Excel リストを使って、オブジェクトが古いフィールド識別子の代わりに新しいフィールド識別子を参照するよう変更する。

      または、

    • 外部ファイルのインポートにより作成されたフィールドを古いフィールド識別子を使って新しいフィールドにコピーする。そして、これらをファイルの仮想フィールドとして使用する。

  2. このフィールドを使用するオブジェクト、OAM を再構築して、機能を再テストします。
  3. すべてをチェックインして戻します。
  • No labels