Page History

...

• 交互参照順序の形式はサポートされていません。IBM i のユーザー索引機能は、単純なバイナリー参照しかサポートしていません。 "SC21-8226" (マニュアル番号) のマニュアルには、IBM i のユーザー (または独立) 索引へのアクセスについての詳しい説明がありますが、以下はこのマニュアルからの引用です。 「各エントリーは、引数のバイナリ値に基づく適切な位置の索引へ挿入されます。他の参照順序はサポートされていません。」
• キー列はすべて昇順で、値は符号なしである必要があります。
• テーブルのキー・リスト内に日付、時刻、時刻スタンプ列を持つテーブルが高速テーブルへミラーリングされる場合は、読み取り専用でテーブルへアクセスする LANSA テーブルは、OAM を使用しません。日付、時刻、時刻スタンプ列ドは、高速テーブル内で英数字列として扱われ ます。したがって、レコードを取り込む際は、値を略さずに入力する必要があります (例えば、1999-1-2 ではなくて、1999-01-02 と入力します)。また、無効な値が入力されると、LANSA ファンクションは日付、時刻または時刻スタンプの有効性を検査せず、単に存在しないというステータスを返すのみです。
• テーブルに含めることのできる列数は、 99 個までです。
• テーブル入力の最大レコード長は、システム・データ域の DC@OSVEROP によって決まります。*HSTABEXTEND オプションが挿入されている場合は、最大入力レコード長は 1988 バイト (OS/400 の制限) で、最大キー長は 108 バイト (LANSA の記憶域とパフォーマンス上の理由による制限) です。キーは 1988 バイトのレコード長に含まれます。*HSTABEXTEND オプションがシステム・データ域にない場合は、テーブル入力レコード長は 108 バイト以内である必要があります。警告：108 バイトを超える入力レコード長は、OS/400 の V2R2M0 よりも前のリリースへは保管できず、またそこから復元することもできません。10 進数の列の場合は、そのバイト長ではなく、10進数の桁数がカウントされます。詳細については『LANSA/AD ユーザーガイド』「コ ンパイルと編集の設定」の「HST に追加する拡張テーブルを許可」を参照してください。
• 基本物理テーブルには、1 つ以上の 1 次キー列が必要です。
• 高速テーブル実行環境においては、テーブル・メンバー、実行時ライブラリ・リストの変更、およびテーブルのオーバーライドまたはリネームという概念はサポートされていません。高速テーブル索引は、LANSA 区画ごとに 1 つあります。索引へのアクセスが必要なアプリケーションが呼び出されると、このアプリケー ションは現在の区画に関連付けられた単一の索引を使用します。
• 選択/除外ロジックは指定できません。
• バッチ制御ロジックは指定できません。
• テーブル内のすべての列に対して、列レベルまたはテーブル・レベルでの「OPEN (開く)」、「READ (読み取り)」、または 「CLOSE (閉じる)」のトリガーは指定できません。
• 仮想列またはロジック (コード) は定義できません。
• テーブルに対する読み取り機密保護は機能しません。つまり、高速テーブルの内容を読み取るファンクションを停止させることはできません。しかし、高速テーブルの内容を変更するファンクションは、通常の方法で停止させることができます (これは、高速索引を変更しているのではなく、実際に通常のデータベース・テーブルを変更しているためです)。 この制約によって、読み取り専用アプリケーションのパフォーマンスを最大限に高めることができます。読み取り機密保護を適用すると、ほんの数件のアクセス しか実行されていない場合でも、テーブルのパフォーマンスに重大な影響を与えます。 事実、機密保護検査にかかる時間は、多数のテーブル・エントリーへのアクセスの実時間よりもはるかに長いためです。
• 高速テーブルとして設定されたテーブルを変更 (INSERT、UPDATE、またはDELETE) するファンクションでは、*DBOPTIMISE、*DBOPTIMISE_BATCH、またはこれらのオプションと結果的に同様の意味を持つ他のオプションを使用することはできません。 この制約がある理由は、実テーブル・データを高速索引にミラーリングするために必要な特別なロジックが、関連の OAM 内にしか存在しないためで す。このため、すべての「テーブル変更機能」は、該当の OAM を使用する必要があります。
• 高速テーブルからの読み取りのみを行うファンクションは、通常の方法で *DBOPTIMISE または *DBOPTIMISE_BATCH を使用することがで きます。
• 高速テーブルの定義 (つまり、レイアウト) を変更する場合は、実テーブルではなく、高速テーブルから読み取るファンクションと OAM をすべて再コ ンパイルする必要があります。この場合も、パフォーマンスを最大にするために、この制約が設けられています。 テーブルは設計と内容については本来大部分が静的であるため、これは問題にはなりません。もし問題になるようであれば、テーブル定義から高速テーブル・オプションを除去してください。
• 高速テーブルから読み取るのみのアプリケーションでは、ロックはサポートされていません。「読み取り専用」ファンクションでレコードのロックが必要な場合は、対象のテーブルは高速テーブル機能に適していません。
• 高速テーブルに対する以下の各機能の使用については検査されませんが、高速テーブルへの「読み取り専用」アクセスが必要なファンクションでは以下の機能はいかなる形式でもサポートされません。
• *OPNQRYF オプションの付いた OPEN コマンドの使用
• 任意の形式での *BLOCKnnn オプションの使用
• 任意の形式での SELECT_SQL オプションの使用
• WITH_RRN、RETURN_RRN または任意の形式の相対レコードのアドレス指定
• 任意の形式の ISS_MSG パラメータ

...

高速テーブルは、通常のテーブルと同様に他のシステムへインポートされます。しかし、テーブルのデータがインポートされた場合、またはテーブル・レイアウ トが変更された場合は、関連の索引は自動的に更新または再フォーマットされることはありません。索引の更新または再フォーマットを行うためには、前述した方法のいずれかを使用して、テーブルとその索引との「再同期」を起動してください。

...