[ |../../index.htm#lansa/laddsnbf_0040.htm]
現在地:
Unicode の扱い
元となるデータベース列が Unicode としてデータベースに格納されている場合、LANSA は次のガイドラインに従って、自動的に適切なフィールドを作成、または再利用します。

• フィールド定義がすでに存在し、属性が SUNI の Char または String が含まれる場合、Unicode データベース用に新規作成されるフィールドはすべて、属性が SUNI の Char、String または CLOB フィールドとして作成されます。
• このルールの唯一の例外は、CCSID が 1208 (UTF-8) の IBM i ネイティブ・タイプ Alpha です。
• 新規のファイル、またはファイルに属性が 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.      すべてをチェックインして戻します。
[ |../../index.htm#lansa/laddsnbf_0040.htm]