ここでは、アプリケーションが Btrieve API を使って実行できるオペレーションについて説明します。各オペレーションに、次の情報があります。

Btrieve API オペレーションの一覧をアルファベット順に示します。

Abort Transaction オペレーション（B_ABORT_TRAN）では、現在のトランザクションを終了し、このトランザクションの開始以降に実行されたすべてのオペレーションの結果を削除します。また、トランザクションによって設定されたすべてのファイルとレコードのロックを解除します。

Abort Transaction オペレーションを発行する前に、Begin Transaction（19 または 1019）オペレーションが正常に実行されている必要があります。

オペレーション コードを 21 に設定します。MicroKernel エンジンでは、オペレーション コード以外の Abort Transaction 呼び出しパラメーターはすべて無視されます。

Abort Transaction オペレーションが正常に終了した場合は、MicroKernel エンジンからステータス コード 0 が返されます。トランザクションの開始以降に発行されたすべての Insert、Update、および Delete オペレーションの結果がファイルから削除されます。

Abort Transaction オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Abort Transaction オペレーションは、ファイルのカレンシー情報にまったく影響しません。

Begin Transaction オペレーション（B_BEGIN_TRAN）では、トランザクションの開始を定義します。トランザクションは、複数の Btrieve API オペレーションを単一イベントとして実行する必要がある場合に有用です。たとえば、いくつかのオペレーションのうち少なくとも 1 つでもオペレーションが正常に終了しないと、データベースの論理的整合性が保てなくなる場合には、トランザクションを使用してください。

一連のオペレーションを Begin Transaction と End Transaction オペレーションで囲んでおくと、明示的な End Transaction（20）でトランザクションの完了を要求しない限り、MicroKernel エンジンはその間に実行された複数のオペレーションをすべて取り消すことができます。トランザクション内で加えられた変更は、End Transaction オペレーションの実行が正常に終了するまで、ほかのユーザーからは見ることができません。

MicroKernel エンジンは、ファイルやパフォーマンスに多大な影響を与えるという理由で、いくつかのオペレーションについてトランザクション中の実行を禁止しています。この特定のオペレーションとは、Set Owner（29）、Clear Owner（30）、Create Index（31）、および Drop Index（32）です。

Begin Transaction オペレーションを発行する前に、先行するトランザクションを終了または中止しておく必要があります。

オペレーション コードを 19 に設定して排他トランザクションを開始するか、1019 に設定して並行トランザクションを開始します。MicroKernel エンジンでは、オペレーション コード以外の Begin Transaction 呼び出しパラメーターはすべて無視されます。

Begin Transaction オペレーションでは、デフォルトのロック バイアスを指定できます。

並行トランザクションの Begin Transaction オペレーションでは、+500 をオペレーション コードに追加できます（1519）。追加すると、トランザクション内の Insert、Update、Delete の各オペレーションが、MicroKernel エンジンによって再試行されなくなります。

さらに、+500 バイアスをデフォルトのロック バイアスと組み合わせることもできます。たとえば、1019 + 500 + 200（1719）を使用すると、Insert、Update および Delete オペレーションの再試行を抑え、並行トランザクションが実行されます。また同時に、単一レコードの読み取りノーウェイト ロックが指定されます。

レコード ロックおよびデータ整合性については、『Zen Programmer's Guide』のほかに『Advanced Operations Guide』に記載されている、Zen データベース サーバーを設定するためのウェイト ロック タイムアウト プロパティを参照してください。

Begin Transaction オペレーションが正常に終了した場合は、MicroKernel エンジンからステータス コード 0 が返されます。

Begin Transaction オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Begin Transaction オペレーションは、ファイルのカレンシー情報にまったく影響しません。

Clear Owner オペレーション（B_CLEAR_OWNER）では、あらかじめ Set Owner オペレーションを使ってファイルに割り当ててあるオーナー ネームを削除します。ファイルがあらかじめ暗号化されている場合は、Clear Owner オペレーションの実行中に MicroKernel エンジンによってファイルの解読も行われます。詳細については、『Advanced Operations Guide』のオーナー ネームを参照してください。

Clear Owner オペレーションが正常に実行されると、それ以降、MicroKernel エンジンはファイルを開いたり変更したりするときにオーナー ネームを要求しなくなります。オーナーを割り当てるときにファイルのデータを暗号化した場合には、MicroKernel エンジンは Clear Owner オペレーションの実行中にデータの解読も行います。暗号化されているデータが多いほど、Clear Owner オペレーションの実行にかかる時間は長くなります。

Clear Owner オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Clear Owner オペレーションは、ファイルのカレンシー情報にまったく影響しません。

Close オペレーション（B_CLOSE）では、指定されたポジション ブロックに関連付けられているファイルを閉じ、そのファイルに対して実行されたロックをすべて解除します。ファイルへのアクセスを終了するとき、アプリケーションでは必ず Close オペレーションを実行する必要があります。Close オペレーションの実行後は、もう一度 Open（0）を発行しない限り、そのファイルにはアクセスできなくなります。

トランザクション中でも、ファイルを閉じることができます。ただし、Close オペレーションを実行しても、トランザクションは終了しません。トランザクションは明示的に終了または中止する必要があります。トランザクションを中止すると、トランザクション中に行われた変更は打ち切られます。トランザクションを終了すると、変更が反映されます。

Close オペレーションが正常に終了した場合は、閉じたファイルに対応するポジション ブロックは有効でなくなります。

Close オペレーションが失敗した場合は、ファイルが開いたままになり、MicroKernel エンジンから次のステータス コードが返されます。

Close オペレーションを実行すると、ファイルの物理カレンシー情報および論理カレンシー情報は消去されます。

Continuous オペレーション（B_CONTINOUS）では、アクティブな MicroKernel エンジン ファイルを閉じることなく、システム バックアップを実行できます。ファイルのバックアップ中に行った変更は、デルタ ファイルと呼ばれる一時ファイルに記憶されます。デルタ ファイルに書き込まれた変更を除き、Continuous オペレーション モードに置かれたすべてのファイルの内容がシステム バックアップの対象になります。バックアップされたファイルが Continuous オペレーション モードから抜けると、MicroKernel エンジンにより、デルタ ファイルの変更がこれらのファイルに自動的にロール インされます。

このオペレーションを使うと、ファイルがアクティブな状態のまま、それを安全にコピーできます。クライアント/サーバー セットアップでは、あるファイルで Continuous オペレーションを開始するクライアントは、そのファイルで Continuous オペレーションを終了するクライアントでもなければなりません。

一連のファイルをバックアップするように定義する場合は、以下の点に留意してください。

Continuous オペレーションを呼び出すサーバー ベースのアプリケーションを作成する場合は、必ず BTRVID を呼び出し、有効なクライアント ID を使用することで、同一クライアントのもとで Continuous オペレーションの開始と終了を行えるようにします。

Btrieve API では、BTRVID 関数を使ってバックアップ セットごとに異なるクライアント ID を指定し、複数のバックアップ セットを定義できます。ただし、同じファイルを 2 つのセットに入れることはできません。

MicroKernel エンジンによってデルタ ファイルからデータ ファイルに変更内容がロール インされているときでも、ユーザーは通常の場合と同じように、MicroKernel エンジン ファイルの更新、挿入および読み取りを引き続き実行できます。MicroKernel エンジンは挿入作業で必要となれば、変更内容のロール イン中でもデルタ ファイルに新しいページを追加します。このため、変更内容が失われることはありません。

アプリケーションで BTRV 関数を使用する場合は、ファイルが Continuous オペレーション モードに入っているときにそのアプリケーションをアンロードしないでください。アンロードすると、対象となるファイルを Continuous オペレーション モードから削除できなくなることがあります。これは、対象となるファイルのオーナーとして MicroKernel エンジンが当初割り当てたデフォルトのクライアント ID が、別のアプリケーションに再割り当てされてしまう可能性があるからです。MicroKernel エンジンでは対象となるファイルの正しいオーナーがわからなくなるため、それらのファイルを Continuous オペレーション モードから削除できなくなってしまいます。

Continuous オペレーション モードに入るとき、または MicroKernel エンジンによってデルタ ファイルからデータ ファイルに変更内容がロール インされている最中にシステムがクラッシュした場合は、システムの再起動後初めてそのファイルを開くときに、MicroKernel エンジンによってすべての変更内容がファイルにロール インされます。

Continuous オペレーションが正常に終了した場合、MicroKernel エンジンからステータス コード 0 が返されますが、データ バッファーおよびデータ バッファー長パラメーターには何の値も返されません。

このオペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

上記のコードに加え、アプリケーションには、 ステータス コード 18 のような標準の I/O エラーが返されることがあります。

MicroKernel エンジンから 0 以外のステータス コードが返される場合、Continuous オペレーションは、エラーを発生させた入力文字列の一部をデータ バッファーに返します。入力文字列が使用されていない場合、データ バッファーにはエラーの原因となったファイル名が返されます。データ バッファー長には、データ バッファー内の出力文字列の長さが反映されます。この場合は、エラーの原因となったファイル名の長さが入ります。

Continuous オペレーションを実行しても、ファイルにカレンシーは確立しません。

Create オペレーション（B_CREATE）では、アプリケーション内部から新しいデータ ファイルを生成できます。Create オペレーションにはファイルの削除または名前変更ができるサブファンクションもあります（Create オペレーションによる削除および名前変更サブファンクションを参照）。

既存のファイルを基に空のファイルを作成する場合は、Create オペレーションを実行する前に必ずその既存ファイルは閉じているようにします。

データ バッファーには、作成するファイルの仕様とキーの仕様を格納します。Create（14）と Stat（15）は同様のデータ バッファー構造体を使用するため、それらのわずかな違いも含め、ここでまとめて説明されています。以下の表は、BTRV タイプ、さらに BTRVEX タイプのエントリ ポイントに関する情報の構造体を示しています。これら両方の説明は Btrieve API 関数にあります。

2 つのタイプのエントリ ポイント間には、仕様内の要素の順序に違いがあることに留意してください。これらの要素の詳細については、以下のトピックを参照してください。

データ バッファーには、ファイル仕様と、0 個以上のキー仕様ブロック、0 個以上の ACS ブロックを格納します。

データ バッファーの先頭 16 バイトまたは 32 バイトにはファイル仕様を格納します。バイト位置は 0 から始まります。レコード長、ページ サイズおよびインデックス数の情報を整数で格納します。

論理固定レコード長。論理レコード長は、ファイル内の固定長データのバイト数です。論理レコード長には可変長データを含めないでください。

ページ サイズ。ページ サイズはファイル形式のバージョンによって決まっています。『Zen Programmer's Guide』のページ サイズの選択を参照してください。次の表は、さまざまなファイル形式バージョンのページ サイズの例を示しています。

レコード数。ファイル内のレコード数です。この値は Stat（15）によって返されます。Create（14）では、このフィールドを 0 に設定します。

キー数。インデックス数はファイルに対して定義しているキーの数です。キー セグメント数ではありません。データオンリー ファイルを作成するには、インデックス数を 0 に設定します。

ファイル バージョン。作成する MicroKernel エンジンのファイル バージョンです。以前のリリースでは、MicroKernel エンジンは 2 バイト整数を使って Create オペレーションでインデックス数を取得していました。インデックスの最大数は 119 であるため、この整数の上位バイトは常に 0 でした。この上位バイトは、これまで Stat（15）オペレーションでファイル バージョンを返すために使用されてきましたが、Create でファイル バージョンを指定するために使用できるようになりました。これにより、以前のアプリケーションでエラーが発生することはありません。Create でサポートされるファイル バージョンは 6.0、7.0、8.0、9.0、9.5、および 13.0 です。これらは、それぞれ 16 進数の値 0x50、0x60、0x70、0x80、0x90、0x95、0xD0 で特定のバイトに示されます。次の表は、さまざまなファイル形式バージョンのファイル バージョン フラグの値を示しています。

追加ポインター数。Create（14）の場合は、将来のキーの追加のために予約する重複ポインター数です。Stat（15）の場合は、残っているポインター数です。予約重複ポインター フラグと共に使用されます。このフラグを使用しないときは、このフィールドを 0 に設定します。

物理ページ サイズ。ページ圧縮ファイル フラグが設定されている場合に使用されます。ページ圧縮フラグが指定されていない場合は、このフィールドを 0 に設定します。このフィールドは、以前は「未使用」とマークされていました。

バージョン 6.x 以降のデータ ファイルでは、論理ページは物理ページに割り当て、ページ アロケーション テーブル（PAT）に格納します。物理ページのサイズは論理ページのサイズと同一です。ページ圧縮は 9.5 以降のファイル形式で使用できます。データベース ページはページ レベルで圧縮されます。各論理ページは、1 つ以上の物理ページ単位に圧縮されます。これら個々の物理ページのサイズは、1 論理ページよりも小さくなります。

物理ページ サイズ フィールドを使用して、ファイルで使用する物理ページ サイズを指定できます。このフィールドで指定する値は、使用される実際の物理ページ サイズを決定するため、512 の倍数にします。0 を指定すると、エンジンは物理ページ サイズのデフォルト値の 512 を使用します。

物理ページ サイズに指定された値は、論理ページ サイズに指定された値よりも大きくすることはできません。物理ページ サイズに指定された値の方が大きい場合、エンジンは論理ページ サイズと同じになるようその値を切り捨てます。論理ページ サイズは物理ページ サイズの倍数になっていなければなりません。倍数でない場合、その論理ページ サイズの値は物理ページ サイズの値のちょうど倍数になるよう切り捨てられます。このような操作の結果として、論理ページ サイズと物理ページ サイズの値が同じになった場合、ページ レベルの圧縮はこのファイルに適用されません。『Zen Programmer's Guide』のページ レベル圧縮を用いたファイルの作成も参照してください。

ファイル フラグ。ファイル フラグ ワードのビットをセットして、ファイル属性を指定します。次の表に、ファイル フラグの値の 2 進、16 進、および 10 進表記を示します。

互換性のないフラグの使用は避けてください。同一ビット位置を使用するフラグ間には互換性はありません。未使用のビットは将来使用するために予約されています。これらのビットを 0 に設定します。

ファイルの属性を組み合わせるには、対応するファイル フラグの値を加算します。たとえば、可変長レコードを含むことができ、ブランク トランケーションを行うファイルを指定するには、ファイル フラグ ワードを 3（2 + 1）に初期化します。可変長レコードのビットが 0 に設定されている場合、MicroKernel エンジンではブランク トランケーションおよび空きスペース スレッショルドのビットを無視します。

ページ プリアロケーションのビットを設定する場合は、ファイル仕様ブロック（アロケーション）の最後の 2 バイトを使用して、ファイルにプリアロケートするページ数を指定する整数値を格納してください。データ圧縮のビットを設定した場合、MicroKernel エンジンでは可変長レコードのビットが無視されます。キーオンリー ファイルのビットを設定した場合、MicroKernel エンジンではシステム データのビットが無視されます。

データベース エンジンは、システム データを使用しており、レコード長が許容最大サイズを超えるファイルについては自動的にデータ圧縮を使用します。『Zen Programmer's Guide』の表 8 を参照してください。

ファイルを作成した後でインデックスの追加が予想される場合、および、そのインデックスには重複した値が含まれるが、繰り返し重複としてマークされない場合は、重複ポインターのビットを設定します。このビットを設定すると、MicroKernel エンジンでは重複した値をリンクするポインターのためにファイルの各レコードにスペースが確保されるようになります。このようなスペースを確保することにより、特に、キーが長く、多数のレコードが重複するキー値を持つことが予測される場合には、検索時間を短縮し、ディスク領域を節約できる場合があります。

特定の番号をキーに割り当てることが必要な場合は、キー番号のビットを設定し、希望するキー番号をキー仕様ブロックの手動割り当てキー番号要素（オフセット 0x0E）に入れます。MicroKernel エンジンではキー番号が連続している必要はありません。つまり、ファイルのキー番号は飛んでいてもかまいません。キーが作成されると、MicroKernel エンジンはデフォルトで、0 から始まるキー番号のうち使用可能な最小の番号をそのインデックスに割り当てます。ただし、アプリケーションによっては、デフォルトの割り当てとは異なるキー番号が必要なこともあります。

ファイルで可変長部割り当てテーブルを使用する場合は、VAT の使用のビットを設定します。VAT を使うには、ファイルで可変長レコードを使用していることが必要です。

プリアロケート ページ数。プリアロケートするページ数を指定できます。ページ プリアロケーションのファイル フラグを指定した場合にのみ、この要素を使用してください。ページ プリアロケーションの詳細については、『Zen Programmer's Guide』のページ プリアロケーションを参照してください。

ファイル仕様のすぐ後に 0 個以上のキー仕様ブロックを配置します。ファイルのキー セグメントごとに 16 バイトまたは 24 バイトののキー仕様ブロックを割り当てます。キー ポジションおよびキー長の情報は整数で格納します。

次の表で示すように、許容されるキー セグメントの最大数は、ファイルのページ サイズおよびファイル形式によって決まります。

『Status Codes and Messages』のステータス コード 26：指定されたキーの数が不正です。および 29：キー長が不正です。を参照してください。

次の表は、キー仕様のデータ バッファー構造体を示しています。各キー仕様ブロックは、BTRV タイプのエントリ ポイントの場合は 16 バイト、BTRVEX タイプのエントリ ポイントの場合は 24 バイトです。2 つのデータ型が示されている場合、1 つめは BTRV で使用され、2 つめは BTRVEX で使用されます。オフセットは、各キー ブロックについて繰り返されます。

キー ポジション。キー ポジションは、キーまたはキー セグメントの開始位置のバイト オフセットです。ポジションは 1 からの相対になります。レコードの先頭に位置するキーは、ポジション 1 から始まります。ポジション 0 はありません。

キー長。キーまたはキー セグメントの長さです。キーの最大長は、すべてのキー セグメントを含めて、255 バイトです。

キー フラグ。キー フラグ ワードのビットをセットして、キー属性を指定します。次の表に、キー フラグの値の 2 進、16 進、および 10 進表記を示します。

互換性のないフラグの使用は避けてください。同一ビット位置を使用するフラグ間には互換性はありません。未使用のビットは将来使用するために予約されています。これらのビットを 0 に設定します。

キーの属性を組み合わせるには、それらの値を合計します。たとえば、キーが拡張キー タイプで、セグメント キーの一部であり、さらに降順に照合される場合は、キー フラグ ワードを 336（256 + 16 + 64）に初期化します。

セグメント キー属性は、データ バッファー内の次のキー仕様ブロックが同一キーの次のセグメントを指すことを示します。セグメント キーについては以下の規則に従ってください。

ACS は、STRING、LSTRING、ZSTRING、WSTRING、および WZSTRING 型のキーにのみ適用されます。大文字小文字の区別を無視し、かつ ACS を使用するキーを定義することはできません。あるキーの一部のセグメントにしか ACS が指定されていないファイルの場合、ACS が指定されているセグメントはその ACS に従ってソートされるのに対し、ACS が指定されていないセグメントはそれぞれの型に従ってソートされます。

拡張データ型。拡張データ型をキー仕様ブロックのバイトにバイナリ値で指定します。表 15 に、拡張データ型に対応するコードを示します。

拡張データ型のコード 12、13、16 および 22 から 24 までは将来使用するために予約されています。CLOB 型は Get Extended オペレーションに含まれていますが、インデックスの作成に使用することはできません。

STRING および UNSIGNED BINARY データ型は、標準型と拡張型のどちらとしても定義できます。これにより、以前のバージョンの Btrieve API を使って開発したアプリケーションとの互換性が保てる一方、新しいアプリケーションで拡張データ型を排他的に使用できるようになります。

キーに割り当てるデータ型に関し、入力したレコードがそのキーに定義されているデータ型に合っているかどうかは、MicroKernel エンジンでは確認されません。たとえば、TIMESTAMP キーをファイルに定義することができますが、そこに文字列を格納することもできます。Btrieve API アプリケーションでは問題なく動作していても、ODBC アプリケーションで同じデータに ODBC TIMESTAMP データ型を使ってアクセスしようとすると、正常に動作しないことがあります。これはおそらく、バイトの形式が異なり、タイムスタンプ値を生成するアルゴリズムが異なるからです。データ型の説明については、『SQL Engine Reference』の Btrieve キーのデータ型を参照してください。

ヌル値。キーの除外値を表します。あるキーをヌル キーとして定義した場合は、各キー セグメントのヌル値として認識させる値を MicroKernel エンジンに提供する必要があります。これは、レガシー ヌルへの参照内にあり、真のヌルには影響しません。ヌル サポートの説明については、『Zen Programmer's Guide』のヌル値を参照してください。

手動割り当てキー番号。MicroKernel エンジンでは、インデックス付きのファイルを作成するときに、アプリケーションで特定のキー番号を割り当てることができます。ファイルの各インデックスに手動でキー番号を割り当てるには、各キー番号をキー仕様ブロックにバイナリ値で指定し、ファイル フラグ ワードにキー番号ビット（0x400）を設定します。

キー番号はファイルで一意であり、キー 0 から昇順に指定されていなければなりません。また、有効な値、つまり、ファイルのページサイズに対するキーの最大数よりも小さい値でなければなりません。

手動でキー番号を割り当てるという機能は、キーを削除して、その削除したキーよりも大きなキー番号を持つすべてのキーの番号を MicroKernel エンジンに付け替えさせないようにする機能と相補関係にあります。たとえば、アプリケーションからインデックスを削除し、MicroKernel エンジンにそれよりも大きな番号を持つキーの番号を付け替えないように指示を出した場合、その後でユーザーが具体的なキー番号を割り当てずに影響を受けたファイルを複製すると、複製したファイルには元のファイルとは別のキー番号が割り当てられます。

ACS 番号。特定の ACS を使用するキーの場合、キー仕様ブロックにより、キーの照合に使用する ACS 番号が示されます。ACS 番号はデータ バッファー内の位置に基づいて決まります。最後のキー仕様ブロックに続く最初の ACS は、ACS 番号 0 になります。ACS 0 の次には ACS 1、その次には ACS2、というように続きます。

コレーティング シーケンスは、Create オペレーションのデータ バッファーで、最後のキー仕様ブロックの直後から 1 つずつ順番に現れます。以下の表で、ACS、ISR、または ICU 照合順序を指定するために使用される 265 バイトについて説明します。

ユーザー定義の ACS ファイル。文字列値を ASCII 標準とは異なる並び順でソートする ACS を作成するには、アプリケーションからデータ バッファに直接 265 バイトを設定する必要があります。

ユーザー定義の ACS ファイルの例については、『Zen Programmer's Guide』のオルタネート コレーティング シーケンスを参照してください。

インターナショナル ソート規則（ISR）。ISR テーブル名を指定するには、アプリケーションからデータ バッファーに直接 265 バイトを設定する必要があります。

Unicode 照合順序。ICU（International Components for Unicode）標準に従って Unicode 照合順序を指定するには、アプリケーションからデータ バッファーに直接 265 バイトを設定する必要があります。

データ バッファー長は、ファイル仕様、キー仕様、および定義されている ACS ファイルを十分に格納できるだけの長さを持つ必要があります。このパラメーターにファイルのレコード長を指定しないでください。

たとえば、BTRV エントリ ポイントを使用して、1 セグメントのキーを 2 つと ACS を 1 つ持つファイルを作成するには、Create オペレーションのデータ バッファーには、以下のように少なくとも 313 バイトの長さが必要です。

Create オペレーションのキー番号は、同名のファイルが既に存在する場合に MicroKernel エンジンが警告を出すかどうか、また、ファイルの作成時に MicroKernel エンジンがローカル エンジンとリモート エンジンのどちらを使用するかを決定します。

次の表を使って、キー番号パラメーターの値を選択します。

Create オペレーションには 2 つのサブファンクションがあり、これを使用してファイルの削除または名前変更ができます。

Pervasive.SQL v8.5 より前は、オペレーティング システムを介して MicroKernel エンジン ファイルを操作することは常に可能でした。これは、オペレーティング システムが Zen ユーザーに与える権限にエンジンが依存していたためです。

v8.5 で Zen データベース セキュリティが導入されると、承認されていないアクセスに対しデータベースがセキュリティで保護されている場合には、このようなオペレーティング システムのアクセス権は除去されることがあります。オペレーティング システムの権限が常に利用できるとは限らなくなるため、プログラムによるファイルの削除や移動のためのオプションは変更される可能性があります。

名前変更と削除のサブファンクションは、代替キー番号を持つ Create オペレーションとして実装されています。新規データ ファイルを作成する場合のようにファイル仕様を指定する必要はありません。Create オペレーションで名前変更と削除サブファンクションを使用するための設定方法を、次の表に示します。

これらのサブファンクションはセキュリティ モデルで動作するように変更されました。その変更点として、サブファンクションは削除または名前変更する MicroKernel エンジン ファイルを示すために、必要に応じて、キー バッファーおよびデータ バッファーでファイル名の代わりに URI を受け入れるようになりました。これにより、セキュリティ情報をオペレーションに指定することができます。URI 接続文字列の詳細については、『Zen Programmer's Guide』のデータベース URI を参照してください。

セキュリティ情報は、通常の Create または Open オペレーションとまったく同様に処理されます。ユーザーは認証され、かつ、既存のファイルに対して、また新しいファイルの保存場所となるディレクトリに対して DB_RIGHT_CREATE、DB_RIGHT_ALTER、および DB_RIGHT_OPEN 権限を持っている必要があります。

Create オペレーションが正常に終了した場合は、MicroKernel エンジンから同名のファイルが既に存在すると警告されるか、仕様に従って新しいファイルが作成されます。新規ファイルにはレコードは含まれていません。Create オペレーションでは作成したファイルを開きません。したがって、ファイルにアクセスするには、アプリケーションで Open オペレーションを実行する必要があります。

Create オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Create オペレーションを実行しても、ファイルにカレンシーは確立しません。

Create Index オペレーション（B_BUILD_INDEX）では、既存のファイルにキーを追加します。

MicroKernel エンジンでは、キーを作成するときに特定のキー番号を割り当てることができます。この機能は、キーを削除して、その削除したキーよりも大きなキー番号を持つすべてのキーの番号を MicroKernel エンジンに付け替えさせないようにする機能と相補関係にあります。アプリケーションがインデックスを削除し、MicroKernel エンジンにそれよりも大きな番号を持つキーの番号を付け替えないように指示を出した場合、その後でユーザーが具体的なキー番号を割り当てずに影響を受けたファイルを複製すると、複製したファイルには元のファイルとは別のキー番号が割り当てられます。

データ バッファーで ACS を定義すると、MicroKernel エンジンは ACS 定義をファイルに追加する前に、まず指定された名前を使って既存の ACS をチェックします。MicroKernel エンジンが指定された名前を持つ既存の ACS を検出した場合、MicroKernel エンジンはファイル内で ACS 定義の複製は行わず、既存の ACS と新しいキーとの関連付けを行います。

キー フラグ ワードに「名前付きの ACS を使用」属性を指定した場合、MicroKernel エンジンはデータ バッファーに指定された ACS 名を使ってファイル内で同名の ACS を検索してから、その ACS を新しいキーに割り当てます。

ファイルが複数の MicroKernel エンジン クライアントによって開かれており、そのクライアントのうちの 1 人が Create Index プロセスを開始した場合、リモート クライアントは、MicroKernel エンジン クライアントによってキーが作成されている間も、開いているファイルに対して Get および Step オペレーションを実行できます。

作成されるキーが autoincrement キーでない場合は、リモート クライアントの Get および Step オペレーションにロック バイアスを使用でき、Create Index プロセスが完了したときに、読み取りオペレーションをさらに発行しなくても、ロックされていたレコードを更新したり削除したりできます。MicroKernel エンジンではキーを作成するためにレコードのイメージを変更する必要がないため、このような処理が可能になります。

ただし、作成されるキーが autoincrement キーである場合は、MicroKernel エンジンではインデックスを構築し、かつ適切なフィールドでゼロ値を使ってすべてのレコードを変更する必要があります。キーの作成前または最中にロック バイアスを使わずに Get または Step オペレーションを実行したリモート クライアントは、キーの作成が正常に終了した後で Update または Delete オペレーションを実行するとき、ステータス コード 80 を受け取ります。

また、あるクライアントがレコードをロックしている最中に、別のクライアントが autoincrement キーを作成しようとすると、MicroKernel エンジンからステータス コード 84 が返されます。同様に、あるクライアントが autoincrement キーのインデックスを作成している最中に、別のクライアントがロック バイアスを使って Get または Step オペレーションを実行しようとすると、MicroKernel エンジンからステータス コード 85 が返されます。

MicroKernel エンジンはファイルに新しいキーを直ちに追加します。このオペレーションの所要時間は、インデックスが作成される総レコード数、ファイルのサイズおよび新しいインデックスの長さによって変わります。

Create Index オペレーションが正常に終了した場合、新しいキーの番号は指定した番号になるか、または次のいずれかになります。

オペレーションの終了次第、新しいキーを使ってデータにアクセスすることができるようになります。

Create Index オペレーションが失敗した場合、新しいインデックスの一部が既に構築されていたとしても、MicroKernel エンジンはそれをすべて削除します。エラーが発生する前に新しいインデックスに割り当てられたファイル ページは、ファイルの空き領域リストに置かれ、レコードを挿入したり別のキーを作成したりするときに再利用されます。

autoincrement キーの作成中にオペレーションが失敗した場合、それまでに変更されている値はそのまま残ります。MicroKernel エンジンから返される可能性のあるステータス コードは次のとおりです。

キーの作成中に処理が中断されても、ファイルのほかのキーを使ってファイルのデータにアクセスすることはできます。しかし、不完全なインデックスを使ってデータにアクセスしようとすると、MicroKernel エンジンから 0 以外のステータス コードが返されます。この問題を解決するには、Drop Index（32）オペレーションを使って不完全なインデックスを削除し、Create Index を再発行してください。

Create Index オペレーションは、ファイルのカレンシー情報にまったく影響しません。

Delete オペレーション（B_DELETE）では、ファイルから既存のレコードを削除します。削除したレコードが占有していたスペースは、新しいレコードを挿入するために再利用されます。

Delete オペレーションは、Extended Get または Extended Step オペレーションの直後に実行した場合には現在のレコードが予測不能であるため、有効なオペレーションにならない可能性があります。

Delete オペレーションを実行した後、それ以降の Get Next または Get Previous オペレーションでは、論理位置を確立した直前のオペレーションと同じキー番号およびキー バッファーを使用する必要があります。別の値を使用すると、MicroKernel エンジンからステータス コード 7 が返されます。

MicroKernel エンジンでは、Get Key（+50）の後に Delete オペレーションを実行することはできません。MicroKernel エンジンで Delete オペレーションを実行する前に、変更しようとしているデータ ページの現在の使用回数と、レコードを読み取った時点のデータ ページの使用回数が比較されます。使用回数を取得するには、MicroKernel エンジンがデータ ページを読み取る必要があります。

Get Key オペレーションではデータ ページを読み取らないので、Delete オペレーションで比較するための使用回数が利用可能になりません。MicroKernel エンジンでは、比較なしにパッシブ並行制御の矛盾チェックを実行できないため、Delete オペレーションは正常に実行されません。Delete オペレーションが正常に実行されないと、MicroKernel エンジンからステータス コード 8 が返されます。

Delete オペレーションが正常に終了した場合は、MicroKernel エンジンによってファイルからレコードが削除され、削除したレコードにロックが設定されていた場合はそのロックが解除され、さらに削除の結果を反映して、すべてのキー インデックスを調整されます。

Delete オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Delete オペレーションを実行してもファイル サイズは小さくなりません。レコードの削除によって生じる空き領域は、今後レコードを追加するときに再利用されます。ディスク容量を回復するには、ファイルを再作成して、そのファイルにすべてのレコードを挿入するしかありません。Rebuild および Defragmenter ユーティリティが、この回復を実現するのに役立ちます。

Delete オペレーションを実行すると、すべての物理位置情報と現在のレコードの論理位置は消去されますが、次のレコードまたは前のレコードの論理位置は変わりません。

Drop Index オペレーション（B_DROP_INDEX）では、既存のファイルからキーを削除します。

システム定義のログ キーを削除した場合、Create Index（31）オペレーションを使ってそれを再構築することができます。

キーを削除する場合、特に指定しなければ、削除したキーよりもキー番号の大きなキーはすべて、MicroKernel エンジンによって自動的に番号が付け替えられます。MicroKernel エンジンは、削除したキーよりも番号の大きなキーの番号を 1 ずつ減らします。たとえば、キー番号 1、4、および 7 を含むファイルがあるとします。キー 4 を削除すると、MicroKernel エンジンは残ったキーの番号を 1 と 6 に付け替えます。

MicroKernel エンジンによってキー番号を自動的に付け替えられたくない場合は、128 というバイアスをキー番号パラメーターに入れる値に加算します。このバイアスにより、キー番号は飛んだままにしておくことができ、その結果、ファイル内のほかのキー番号に影響を及ぼすことなく、壊れたインデックスを削除し、そのインデックスを作成し直すことができます。インデックスを再構築するには、Create Index（31）を使います。このオペレーションではキー番号を指定できます。

ただし、キーを削除し、それよりキー番号の大きなキーの番号を付け替えなかった場合、その後でユーザーが具体的なキー番号を割り当てずに影響を受けたファイルを複製すると、複製したファイルには元のファイルとは別のキー番号が割り当てられます。

Drop Index オペレーションが正常に終了した場合、指定したインデックスは MicroKernel エンジンによって削除され、そのインデックスに割り当てられていたページは、今後の使用のために空き領域のリストに配置されます。また、特に指定しなければ、MicroKernel エンジンでは削除したキーよりもキー番号の大きなキーの番号が付け替えられます。

Drop Index オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

MicroKernel エンジンがインデックスを削除中に処理が中断されても、ファイルのほかのキーを使ってファイルのデータにアクセスすることはできます。しかし、不完全なインデックスを使ってファイルにアクセスしようとすると、MicroKernel エンジンからステータス コード 56 が返されます。処理が中断された場合は、Drop Index オペレーションを再発行してください。

Drop Index オペレーションは、ファイルの物理カレンシー情報にはまったく影響しません。ただし、直前に論理カレンシーを確立するために使用したキーを削除すると、論理カレンシーは消去されます。

End Transaction オペレーション（B_END_TRAN）では、トランザクションを終了し、データ ファイルに適切な変更を加えます。また、トランザクションによって設定されたすべてのファイルとレコードのロックを解除します。

End Transaction オペレーションを発行する前に、Begin Transaction（19 または 1019）が正常に終了している必要があります。

オペレーション コードを 20 に設定します。MicroKernel エンジンでは、オペレーション コード以外の End Transaction 呼び出しパラメーターはすべて無視されますが、将来のリリースとの互換性を確保するために 0 に初期化してください。

End Transaction オペレーションが正常に終了した場合は、トランザクション内で実行されたすべてのオペレーションの結果がファイルに保存されます。End Transaction オペレーションを実行した後でトランザクションを中止することはできません。

End Transaction オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードが返されます。

End Transaction オペレーションは、ファイルのカレンシー情報にまったく影響しません。

Find Percentage オペレーション（B_GET_PERCENT）は、スクロール バーを実装するウィンドウ指向のアプリケーションで使用することのできる 2 つの Btrieve API オペレーションのうちの 1 つです。もう 1 つのオペレーションは Get By Percentage（44）です。Find Percentage では、キー パスまたはファイル内でのレコードの物理位置を基準として、それに対応するレコードのおおよその位置を返します。位置はパーセンテージ値で表されます。パーセンテージ値の範囲の定義については、結果を参照してください。

Find Percentage オペレーションは、特にスクロール バーの実装をサポートする目的で用意されています。このオペレーションの精度、つまり、返されたパーセンテージ値がレコードまたはキー値の位置をどれだけ精確に反映しているかどうかは、さまざまな要因によって影響を受けます。このため、スクロール バーの実装以外の目的で使用する場合は、このオペレーションの精度を信頼しないでください。

Find Percentage オペレーションを最適化するため、MicroKernel エンジンでは、ファイルのレコードはデータ ページ間に、キーはインデックス ページ間に均等に分布していることを前提としています。ただし、分布状態は次のような状況によって影響を受けます。

精度の設定は任意であり、パーセンテージを測定する要素を選択することができます。Zen 9 より前のリリースでは、この値は常に 10000 でした。

精度を指定する場合は、以下の手順に従ってください。

次の表は、これらの手順における位置とレイアウトをまとめています。

たとえば、365 件のレコードが入っているファイルから 100 番目のレコードを取得したい場合、パーセンテージに 100、精度に 365 を使用して Find Percentage（45）を実行することができます。

Find Percentage オペレーションが正常に終了した場合は、MicroKernel エンジンによって、指定したキー値またはレコードの相対位置がデータ バッファーに返されます。この位置は、キー パスまたはファイルにおけるオフセットのパーセンテージとして表され、0（0%）から 10000（100.00%）までの範囲の値になります。これは、物理位置でも論理位置でもないので注意してください。

パーセンテージ値は、下位バイト、上位バイトの順の 4 バイト整数として返されます。たとえば、デフォルトの精度を使用する場合は次のようになります。

また、オペレーションが正常に終了した場合には、MicroKernel エンジンからデータ バッファー長に少なくとも 4 が返されます。

Find Percentage オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Find Percentage オペレーションを実行しても、カレンシー情報は変更されません。

Get By Percentage オペレーション（B_SEEK_PERCENT）は、スクロール バーを実装するウィンドウ指向のアプリケーションで使用することのできる 2 つの Btrieve API オペレーションのうちの 1 つです。もう 1 つは Find Percentage（45）です。Get By Percentage オペレーションは、ファイル内のレコードの相対位置によってレコードを取得します。この位置は、オペレーションを呼び出すときに指定したパーセンテージ値に基づきます。また、この位置は特定のキー パスを基準とするのか、ファイル内のレコードの実際の物理位置を表すのかを指定する必要があります。

精度を指定しない場合（精度を参照）、データ バッファー パラメーターの最初の 2 バイトに対するパーセンテージ値の許容範囲は、0（キー パスまたはファイルの先頭を表します）から 10000（キー パスまたはファイルの末尾を表します）までです。この値は、小数点以下 2 桁を含むものとして、0% から 100.00% の範囲に対応しています。ファイル中の 33.33% あたりにあるレコードを検索する場合は、データ バッファーに値 3333 を渡します。値は、下位バイト、上位バイトの順の整数として格納してください。たとえば、ファイル内の 50% の地点をシークするには、5000（0x1388）という値を使います。0x1388 の下位バイトと上位バイトを入れ替え、0x88 と 0x13 をデータ バッファー パラメーターの先頭の 2 バイトに格納します。

検索の精度を指定する場合は、精度で指定されているようにデータ バッファー パラメーターを設定します。

Get By Percentage オペレーションは、特にスクロール バーの実装をサポートする目的で用意されています。このオペレーションの精度、つまり、返されたレコードがファイル内の指定したパーセンテージ地点に実際に位置しているかどうかは、さまざまな要因によって影響を受けます。このため、スクロール バーの実装以外の目的で使用する場合は、このオペレーションの精度を信頼しないでください。

Get By Percentage オペレーションを最適化するため、MicroKernel エンジンでは、ファイルのレコードはデータ ページ間に、キーはインデックス ページ間に均等に分布していることを前提としています。ただし、分布状態は次のような状況によって影響を受けます。

精度の設定は任意であり、パーセンテージを測定する要素を選択することができます。Zen 9 より前のリリースでは、この値は常に 10000 でした。

精度を指定する場合は、以下の手順に従ってください。

たとえば、365 件のレコードが入っているファイルから 100 番目のレコードを取得したい場合、パーセンテージに 100、精度に 365 を使用して Get By Percentage（44）を実行することができます。

Get By Percentage オペレーションが正常に終了した場合は、MicroKernel エンジンによって、指定したキー パスを基準とする位置またはファイル内の物理位置にあるレコードがデータ バッファーに返されます。さらに MicroKernel エンジンからは、データ バッファー長パラメーターにレコード長がバイト単位で返されます。キー パスによってレコードをシークした場合は、MicroKernel エンジンからキー バッファー パラメーターに指定したキー パスのキー値が返されます。物理レコード順によってレコードをシークした場合は、MicroKernel エンジンからキー バッファー パラメーターには何の情報も返されません。

Get By Percentage オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

指定したキー パスを基準としてレコードをシークするとき、Get By Percentage オペレーションが正常に終了した場合は、指定したキー番号と取得したレコードのそれぞれに基づいて新しい論理カレンシーおよび物理カレンシーが確立されます。

ファイル内のレコードの物理位置を基準としてレコードをシークするとき、Get By Percentage オペレーションが正常に終了した場合は、取得したレコードに基づいて新しい物理カレンシーが確立されます。

Get By Percentage オペレーションが失敗した場合、MicroKernel エンジンではカレンシーは変更されません。

Get Direct/Chunk オペレーション（B_GET_DIRECT）では、チャンクと呼ばれるレコードの部分を 1 つまたは複数取得できます。このオペレーションは、最大データ バッファー サイズより長いレコードを含むファイルで特に役に立ちます。データ バッファー パラメーターの長さには制限があるため、このようなレコードは長すぎて、ほかの Get および Step オペレーションでは取得できません。アプリケーションでは、物理アドレスを指定することで、チャンクが取得されるレコードを指定します。通常、レコード内でのチャンクの位置は、そのオフセットと長さで指定されます。

データ バッファーでは、次のチャンク ディスクリプターのいずれかを使用します。

次の例は、ランダムに配置されている 3 つのチャンク（[*] がある部分）を含むレコードを示しています。チャンク 0（バイト 0x12 から 0x16）、チャンク 1（バイト 0x2A から 0x31）、およびチャンク 2（バイト 0x41 から 0x4E）です。

ランダム チャンクを取り出すには、次の表に基づいてデータ バッファー内に構造体を作成する必要があります。

次の表は、BTRV エントリ ポイントを使って直接ランダム チャンクを取り出す場合の、32 ビット アプリケーション用データ バッファーの例を示しています。

同じ長さのチャンクがレコード全体にわたって等間隔に配置されている場合は、矩形チャンク ディスクリプターを使って、取得するすべてのチャンクを記述することができます。たとえば、次のような図を考えてみましょう。この図は、レコード内のオフセット 0x00 から 0x4F までを表しています。

このレコードには 3 つのチャンク（[*] がある部分）が含まれています。チャンク 0（バイト 0x19 から 0x1C）、チャンク 1（バイト 0x29 から 0x2C）、およびチャンク 2（バイト 0x39 から 0x3C）です。各チャンクはどれも 4 バイトの長さで、チャンク同士は、各チャンクの先頭から計算すると、いずれも合計 16（0x10）バイトずつ離れています。

1 つの矩形ディスクリプターを使って、3 つのチャンクをすべて取得できます。矩形チャンクを取り出すには、次の表に基づいてデータ バッファー内に構造体を作成する必要があります。

間接矩形ディスクリプターを使用するときは、取得されたチャンクがチャンク ディスクリプターを上書きしないように、ユーザー データ ポインターが初期化されていることを確認してください。MicroKernel エンジンは、返されたチャンクをユーザー データ要素が示す場所にコピーするとき、ディスクリプターを使用します。チャンク ディスクリプターを上書きしてしまった場合は、MicroKernel エンジンからステータス コード 62 が返されます。

矩形がメモリ内にあるとき、各行の間隔がレコードとして格納されているときと同じバイト数になる場合は、アプリケーションの行間隔を行間隔と同じ値に設定します。しかし、矩形がアプリケーションのメモリ内で再配置され、行の間隔が何バイトか増減する場合は、アプリケーションの行間隔により、その情報を MicroKernel エンジンに渡すことができます。

間接矩形ディスクリプターを使用するときは、MicroKernel エンジンはユーザー データ要素およびアプリケーションの行間隔要素を使って、取得後のデータの格納場所を決定します。MicroKernel エンジンは 1 行目のデータを、ユーザー データのオフセット 0 に格納します。MicroKernel エンジンは 2 行目のデータを、ユーザー データ + アプリケーションの行間隔で指定されるアドレスに格納します。MicroKernel エンジンは 3 行目のデータを、ユーザー データ + (アプリケーションの行間隔 * 2) で指定されるアドレスに格納します。以下同様です。

次の表は、BTRV エントリ ポイントを使って直接矩形チャンクを取り出す場合の、32 ビット アプリケーション用データ バッファーの例を示しています。

これまでに述べたサブファンクションの値にバイアス 0x40000000 を加算すると、MicroKernel エンジンではレコード内の物理カレンシー（つまり、レコード内の現在の物理位置）に基づいてサブファンクションのオフセット要素の値が算出されます。ネクストインレコード サブファンクションを使用する場合、MicroKernel エンジンではチャンク ディスクリプターのオフセット要素は無視されます。

Get Direct/Chunk オペレーションが正常に終了した場合、直接チャンク ディスクリプターを使用しているときは、MicroKernel エンジンではデータ バッファーにチャンクが順に返されます。間接ランダム チャンク ディスクリプターを使用しているとき、MicroKernel エンジンでは各チャンクのユーザー データ要素で指定した場所にデータが返されます。また、間接矩形ディスクリプターを使用しているとき、MicroKernel エンジンではユーザー データ要素およびアプリケーションの行間隔要素から計算される場所にデータが返されます。

さらに MicroKernel エンジンから、データ バッファー長パラメーターには、取得されたチャンクの長さの総計が格納されます（この戻り値は、チャンクが取得されて直接データ バッファーに格納されたか、間接ディスクリプターによってチャンクが取得され別の場所に格納されたかどうかに関係なく、取得された全バイト数を反映しています）。オペレーションが部分的にしか正常に実行されなかった場合、アプリケーションではデータ バッファー長パラメーターに返された値を使って、どのチャンクが取得されなかったか、また最後のチャンクの何バイトまでが取得されたかを調べることができます。

いずれかのチャンクで、開始位置がレコードの末尾を超えてしまう場合（結果として、MicroKernel エンジンからステータス コード 103 が返されます）、またはチャンクのオフセットと長さの合計がレコード長を超えてしまう場合には、Get Direct/Chunk オペレーションの一部だけが正常に実行されます。後者の場合は MicroKernel エンジンからステータス コード 0 が返されますが、このオペレーションに後続のチャンクがある場合、その処理は中止されます。

次のステータス コードは、Get Direct/Chunk オペレーションの一部だけが実行されたことを示します。MicroKernel エンジンからこれらのステータス コードのいずれかが返された場合は、アプリケーションでデータ バッファー長パラメーターの戻り値を調べて、MicroKernel エンジンから実際に返されたデータ量を確認する必要があります。

MicroKernel エンジンから次のステータス コードが返される場合、データはまったく取得されません。

Get Direct/Chunk オペレーションは、論理カレンシーにまったく影響しません。物理カレンシーについては、チャンクが取り出されたレコードが現在の物理レコードになります。

Get Direct/Record オペレーション（B_GET_DIRECT）では、定義されているキー パスではなく、ファイル内の物理位置を使ってレコードを取得します。

以下のような操作を実行する場合は、Get Direct/Record オペレーションを使用してください。

Get Direct/Record オペレーションが正常に終了した場合、MicroKernel エンジンでは要求したレコードがデータ バッファーに、レコード長がデータ バッファー長に、指定したキー パスのキー値がキー バッファーにそれぞれ返されます。

Get Direct/Record オペレーションが失敗し、要求したレコードを MicroKernel エンジンが取得できなかった場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Get Direct/Record オペレーションを実行すると、既存の論理カレンシー情報が消去され、指定したキー番号に従って新しい論理カレンシーが確立されます。物理カレンシー情報にはまったく影響しません。

Get Directory オペレーション（B_GET_DIR）では、指定された論理ディスク ドライブの現在のディレクトリを返します。

Get Directory オペレーションはいつでも発行することができます。キー バッファーには少なくとも 65 文字の長さが必要です。

MicroKernel エンジンでは、オペレーションが正常に終了した場合、バイナリ 0 で終端する現在のディレクトリがキー バッファーに返されます。

Get Directory オペレーションは、ファイルのカレンシー情報にはまったく影響しません。

Get Equal オペレーション（B_GET_EQUAL）では、キー バッファーに指定されたキー値と等しいキー値を持つレコードを取得します。キーの重複が可能な場合は、同じキー値を持つグループの中で先頭のレコード（作成順）が取得されます。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get Equal オペレーションが正常に終了した場合は、MicroKernel エンジンでは要求したレコードがデータ バッファーに、そのレコードの長さがデータ バッファー長に返されます。

Get Equal オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

このオペレーションは、キーのヌル インジケーター セグメントにゼロ以外の値が含まれている場合にはステータス コード 4 を返します。Get Equal を使ってヌルのレコードは検索できません。これは、ヌルの定義はあいまいなものであり、どの値とも等しくならないからです。ヌル値の検索が必要な場合は、Get First オペレーションに続けて Get Next オペレーションを使用します。

Get Equal オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。

Get First オペレーション（B_GET_FIRST）では、指定されたキーに基づいて先頭の論理レコードを取得します。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get First オペレーションが正常に終了した場合は、MicroKernel エンジンでは要求したレコードがデータ バッファーに返され、対応するキー値がキー バッファーに格納され、さらにそのレコードの長さがデータ バッファー長に返されます。

Get First オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Get First オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。論理位置の直前は、ファイルの先頭よりも前を指すことになります。

Get Greater Than オペレーション（B_GET_GT）では、キー番号で指定されたフィールドが、キー バッファーの値よりも次に大きな値を含むレコードを取得します。キーの重複が可能な場合は、同じキー値を持つグループの中で先頭のレコード（作成順）が取得されます。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get Greater Than オペレーションが正常に終了した場合、MicroKernel エンジンでは要求したレコードがデータ バッファーに、キー値がキー バッファーに、さらにそのレコードの長さがデータ バッファー長に格納されます。

Get Greater Than オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Get Greater Than オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。

Get Greater Than or Equal オペレーション（B_GET_GE）では、キー番号で指定されたキーが、キー バッファーに指定された値と等しいかそれよりも大きな値を持つレコードを取得します。MicroKernel エンジンではまず、等しいという条件を満たすレコードが検索されます。キーの重複が可能な場合は、同じキー値を持つグループの中で先頭のレコード（作成順）が取得されます。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get Greater Than or Equal オペレーションが正常に終了した場合、MicroKernel エンジンでは要求したレコードがデータ バッファーに、キー値がキー バッファーに、さらにそのレコードの長さがデータ バッファー長に格納されます。

Get Greater Than or Equal オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Get Greater Than or Equal オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。

Get Key バイアスを使用すると、実際にデータ レコードを取得することなく Get オペレーションを実行できます。Get Key を使って、ファイル内にある値が存在するかどうかを検出できます。一般に、Get Key オペレーションは対応する Get オペレーションよりも高速に実行できます。Get Key オペレーションは、以下のいずれかの Get オペレーションと共に使用します。

パラメーターは対応する Get オペレーションと同様です。ただし、MicroKernel エンジンではデータ バッファー長の設定は無視され、データ バッファーにはレコードが返されません。

Get Key オペレーションの前提条件は、対応する Get オペレーションの前提条件と同じです。

MicroKernel エンジンでは、Get Key（+50）の後に Delete または Update オペレーションを実行することはできません。MicroKernel エンジンで、Delete または Update オペレーションを実行する前に、変更しようとしているデータ ページの現在の使用回数と、レコードを読み取った時点のデータ ページの使用回数が比較されます。使用回数を取得するには、MicroKernel エンジンがデータ ページを読み取る必要があります。

Get Key オペレーションではデータ ページを読み取らないので、Delete または Update オペレーションで比較するための使用回数が利用可能になりません。MicroKernel エンジンでは、比較なしにパッシブ並行制御の矛盾チェックを実行できないため、Update または Delete オペレーションは正常に実行されません。Update または Delete オペレーションが正常に実行されないと、MicroKernel エンジンからステータス コード 8 が返されます。

MicroKernel エンジンで要求したキーが検出されると、そのキー値がキー バッファーに格納され、ステータス コード 0 が返されます。そうでない場合は、MicroKernel エンジンからキー値を検出できなかった理由を示すステータス コードが返されます。

Get Key オペレーションを実行すると、対応する Get オペレーションと同様の方法で現在のポジショニングが確立されます。ただし、Get Key オペレーションの対象となるキーが重複を許可している場合、MicroKernel エンジンでは取得された現在のキー値の重複インスタンスは無視されます。Get Key オペレーションの実行後、論理位置の直前は次に小さなキー値を含むレコードを指します。また、論理位置の直後は次に大きなキー値を含むレコードを指します。

たとえば、Smith が 8 回と Smythe が 1 回出現する姓のキーを対象に、Get Key を Get Equalオペレーション（55）と共に実行したとします。論理位置の直後は次の Smith ではなく、Smythe を指すことになります。

Get Key オペレーションではどれか 1 つのレコードが識別されるわけではないため、MicroKernel エンジンでは Get Key オペレーションに続けて Update または Delete オペレーションを実行することはできません。

Get Last オペレーション（B_GET_LAST）では、指定されたキーに基づいて末尾の論理レコードを取得します。末尾のキー値が重複している場合は、同じキー値を持つグループの中で末尾のレコードが返されます。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get Last オペレーションが正常に終了した場合は、MicroKernel エンジンでは要求したレコードがデータ バッファーに返され、対応するキー値がキー バッファーに格納され、さらにそのレコードの長さがデータ バッファー長に返されます。

Get Last オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Get Last オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。論理位置の直後は、ファイルの末尾よりも後を指すことになります。

Get Less Than オペレーション（B_GET_LT）では、キー番号で指定されたキーが、キー バッファーに指定された値よりも次に小さな値を持つレコードを取得します。キーの重複が可能な場合は、同じキー値を持つグループの中で末尾のレコード（作成順）が取得されます。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get Less Than オペレーションが正常に終了した場合、MicroKernel エンジンではレコードがデータ バッファーに、そのレコードのキー値がキー バッファーに、さらにそのレコードの長さがデータ バッファー長に返されます。

Get Less Than オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Get Less Than オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。

Get Less Than or Equal オペレーション（B_GET_LE）では、キー番号で指定されたキーが、キー バッファーに指定された値と等しいかそれよりも小さな値を持つレコードを取得します。MicroKernel エンジンではまず、等しいという条件を満たすレコードが検索されます。キーの重複が可能な場合は、同じキー値を持つグループの中で末尾のレコード（作成順）が取得されます。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get Less Than or Equal オペレーションが正常に終了した場合、MicroKernel エンジンではレコードがデータ バッファーに、そのレコードのキー値がキー バッファーに、さらにそのレコードの長さがデータ バッファー長に返されます。

Get Less Than or Equal オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Get Less Than or Equal オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。

Get Next オペレーション（B_GET_NEXT）では、指定されたキーに基づいて、論理位置で次にあるレコードを取得します。Get Next オペレーションを使うと、重複するキー値を持つレコードのグループの中でレコードを検索できます。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get Next オペレーションが正常に終了した場合、MicroKernel エンジンではレコードがデータ バッファーに、そのレコードのキー値がキー バッファーに、さらにそのレコードの長さがデータ バッファー長に返されます。

Get Next オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

このオペレーションの実行により、論理位置の直後がファイルの末尾よりも後を指す場合は、ステータス コード 9 が返されます。

Get Next オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。

Get Next Delete Extended オペレーション（B_GET_NEXT_EXT_DELETE）では、指定されたキーに基づき、論理位置の直後からファイルの末尾へ向かって 1 つまたは複数のレコードを検索します。検索したレコードをフィルター条件と比較し、条件に一致するレコードを削除します。フィルター条件は論理式の形を取り、キー フィールドに限定されません。

このトピックで述べるように、このオペレーションが使用する入力および出力バッファー構造体、および返す結果は、Get Next Extended（36）に記載されているものと同じです。詳細については、当該オペレーションを参照してください。

Get Next Extended（36）の以下のトピックで、Extended オペレーションの入力バッファーの構造体とそのフィルター セグメントの使用について、さらに結果を返す出力バッファーの構造体について説明されています。

Get Next Delete Extended オペレーションが正常に終了した場合は、MicroKernel エンジンから次の情報が返されます。

Get Next Delete Extended オペレーションは、ほかの Step Extended および Get Extended オペレーションと同じ原因で失敗する可能性があり、次のいずれか 1 つが返されます。

出力バッファーの長さがゼロの場合、レコードは削除されていません。ただし、オペレーションが失敗する前に一部のレコードを正常に削除している可能性があります。以下に、このような一部成功のいくつかの例を示します。

このような場合、出力バッファー長はゼロより大きく、バッファーの最初の 2 バイトは削除されたレコード数のカウントを提供します。

MicroKernel エンジンではフィルター条件で使用するフィールドと演算子によって、要求を最適化できる場合があります。拒否レコードに達すると、ステータス コード 64 が返され、ファイルの未検索の部分にはフィルター条件を満たすレコードがそれ以上ないことが示されます。

Get Next Delete Extended オペレーションでは、カレンシーは確立しません。ただし、Get Next オペレーションまたは Get Previous オペレーションを実行することができ、次または前の論理位置は有効です。また、Get Position（22）および Get Direct/Record（23）を使用することにより、有効な現在の位置も使用可能になります。

次のリストは、選定されたステータス コードとフィルター条件の関係を示しています。

Get Next Extended オペレーション（B_GET_NEXT_EXTENDED）では、指定されたキーに基づき、論理位置の直後からファイルの末尾へ向かって 1 つまたは複数のレコードを検索します。検索したレコードをフィルター条件と比較し、条件に一致するレコードを取得します。フィルター条件は論理式の形を取り、キー フィールドに限定されません。

Get Next Extended オペレーションでは、レコードから指定した部分だけを抽出し、その部分だけをアプリケーションに返すこともできます。

以下のトピックで、Extended オペレーションの入力バッファーの構造体とそのフィルター セグメントの使用について、さらにオペレーションの結果を返す出力バッファーの構造体について説明します。

次の表は、Extended オペレーションの入力バッファーの構造体を示しています。このバッファーはすべての Extended オペレーションに適用されますが、既に述べたように使用方法に違いがあります。

比較演算子コードを Extended オペレーション コード 7（バイアス +8）として指定するオペレーションでは、次の表に示すように、照合順序フィールドは既存の ACS、ISR テーブル、ICU 照合順序、またはコード ページを参照することができます。形式は、識別バイトの後に名前が続く形です。

JSON QUERY 演算子を使用すると、JSON 文字列として格納されたデータを含んでいるレコードをフィルターすることができます。レコード内で、文字列データは ZSTRING または CLOB データ型として格納されている可能性があります。フィルター要素には比較定数を含める必要があります。比較定数は、レコード内の JSON データが満たしている必要のあるフィルター条件を指定する文字列とします。この文字列は JSON クエリとも呼ばれ、文字列自体は、ここに記載されている例に示すように、JSON を使用して指定されます。

JSON QUERY 演算子は現在、コード ページ、ACS、および照合順序をサポートしていません。ZSTRING または CLOB データ フィールドのエンコードは、シングル バイトの Windows ANSI コード ページまたは UTF-8 にすることができます。

JSON QUERY 演算子を使用する場合、フィルター条件に指定する比較定数は、次の例に示すような JSON 構文を使用する有効な JSON クエリでなければなりません。これはヌルで終了している必要があります。フィルター文字列が適切な JSON 形式でない場合、Extended オペレーションは、ディスクリプターが不正であることを示すステータス コード 62 で失敗します。

JSON QUERY 演算子を使用するとき、比較する対象のレコードのフィールドが JSON 仕様に従っていない場合は、レコードは条件を満たさないものとして扱われます。

次の例は、JSON のフィルタリングに必要な構文を示しています。

Bureau of Transportation Statistics データから派生した別の例では、JSON 形式の航空会社の飛行データのレコードには、次のようなフィールドがあるかもしれません。

ハーツフィールド ジャクソン アトランタ国際空港（Hartsfield-Jackson Atlanta International Airport（ATL））においてアメリカン航空（American Airlines（AA））に関連するレコードを検索するには、次のクエリ文字列を使用できます。

クエリ文字列に JSON 形式を使用していることに注意してください。構文の確認に JSON の検証ツールが役立つかもしれません。

MicroKernel エンジンでは Extended オペレーションのフィルターに含まれる AND および OR 演算子は、厳密に左から右へ向かって解釈されます。次の規則に従って、フィルター内の式の評価を続けていきます。

次のいずれかの条件を満たすと、レコードの検索は中止されます。

フィルター条件を満たす次のレコード全体を取得するには、フィルター部分を設定し、次のようにディスクリプター フィールドを設定します。

フィルター条件を使わずに次の 12 件のレコードを取得し、各レコードから 4 つのフィールドを抽出するには、論理式の項の数を 0 に設定し、次のようにディスクリプター フィールドを設定します。

Extended Get または Step オペレーションを使ってレコードの 1 つ以上のフィールドまたは部分を取得するときは、データ バッファーがオペレーションから返される情報を十分に格納できることを確認しておく必要があります。次の表は、戻り出力バッファーの構造体を示しています。

返されたすべてのレコードまたはレコードのフィールドが固定長である場合、戻りデータ バッファー内のデータの位置は簡単に計算できます。しかし、Extended オペレーションから返されたデータ バッファーからレコードの可変長部分を抽出するには、さらに特別な手順を踏む必要があります。

レコードの可変長部分が返されるとき、MicroKernel エンジンは戻りデータ バッファー内に余分なレコード イメージを詰め込みません。したがって、レコードの可変長部分が占有する最大のバイト数を想定して戻りデータ バッファー内の領域を確保しても、実際に返されたデータがその最大値を下回る場合、MicroKernel エンジンでは次に返されたフィールドのフィールド記述は現在のフィールドのデータの直後から始まることになります。

たとえば、エントリ ポイントが 4 バイトのレコード アドレスを使用すると仮定して、固定レコード長が 100 バイトで、可変長部分は最大 300 バイトになると推定されるときに、5 件のレコードの可変長部分だけを取得したいとします。入力バッファーのディスクリプター要素を使って、フィールド長を 300 に設定し、フィールドのオフセットを 100 に設定します。戻りバッファーについては、次の計算式で示すように、レコード数を示す 2 バイトと、レコード当たり 306 バイト（つまり、長さの 2 バイト、アドレスの 4 バイト、およびデータの 300 バイト）を加算する必要があります。

2 + ((2 バイト + 4 バイト + 300 バイト) * 5) = 1532 バイト

しかし、返された先頭レコードの可変長部分には 50 バイトのデータしかなかったとします。その結果、2 バイトから成る 2 番目に返されるレコードの長さは、データ バッファーのオフセット 58、つまり先頭レコードのフィールド イメージの直後に格納されることになります。こうした状況でもアプリケーションでは、MicroKernel エンジンからデータ バッファーに返された長さ、位置、およびデータを正確に解析する必要があります。

Get Next Extended オペレーションが正常に終了した場合は、MicroKernel エンジンから次の情報が返されます。

Get Next Extended オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

MicroKernel エンジンは 0 以外のステータス コードに加え、有効なデータも返すことがありますが、返された最後のレコードは不完全です。返されたバッファー長が 0 より大きい場合は、抽出されたデータのバッファーを確認してください。

レコードが短すぎるためにフィールドを部分的にしか格納できない場合は、MicroKernel エンジンではその部分フィールドも含め、格納できるだけのレコード部分が返されます。部分フィールドが抽出される最後のフィールドである場合、エンジンではオペレーションが続行されます。そうでない場合、オペレーションは中止され、ステータス コード 22 が返されます。

たとえば、Get Next Extended オペレーションで、2 件の可変長レコードから 3 つのフィールドを取得するとします。最初のレコードは 55 バイトで、2 番目のレコードは 50 バイトの長さだとします。出力バッファーには 50 バイトのデータを返すことができます。取得する 3 つのフィールドは次のように定義されています。

MicroKernel エンジンで Get Next Extended オペレーションが実行されるとき、最初のレコードは問題なく返されます。しかし、次にフィールド 2 の 10 バイトを抽出しようとすると、オフセット 45 とレコードの末尾のオフセット 49 の間では 5 バイトしか取得できないことが MicroKernel エンジンによって検出されます。この時点で、MicroKernel エンジンはフィールド 2 の不足している 5 バイト分を詰め込まないため、フィールド 3 は抽出できなくなります。その代わりに、ステータス コード 22 が返され、フィールド 1 全体とフィールド 2 の先頭 5 バイトが戻りデータ バッファーに格納されます。

MicroKernel エンジンではフィルター条件で使用するフィールドと演算子によって、要求を最適化できる場合があります。拒否レコードに達すると、ステータス コード 64 が返され、ファイルの未検索の部分にはフィルター条件を満たすレコードがそれ以上ないことが示されます。

Get Next Extended オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立されます。検索された最後のレコードが現在のレコードになります。このレコードは、フィルター条件を満たして取得されたレコードか、またはフィルター条件を満たさないために拒否されたが、まだ最適化の範囲を超えていないレコードのいずれかです。たとえば、Extended オペレーションがステータス 9（ファイルの終わり）を返した場合は、ファイルの末尾のレコードが現在のレコードになります。ステータス 60（リジェクト カウントに達しました）が返された場合は、拒否された最後のレコードが現在のレコードです。ステータス 64（フィルター制限に達しました）が返された場合には、最適化条件を満たす最後のレコードが現在のレコードになります。これ以降のレコードは最適化の範囲を超えていることを確認するために、MicroKernel エンジンが次のレコードを検索する必要があったとしても、現在のレコードの設定は条件を満たしていた以前のレコードに戻されます。

Get Position オペレーション（B_GET_POSITION）では、現在のレコードの物理位置を返します。Get Position オペレーションを発行するときに物理カレンシーが確立されていないと、オペレーションは正常に実行されません。レコードの位置（アドレス）を決定できれば、Get Direct/Record（23）を使って、ファイル内の物理位置を基にそのレコードを直接取得できるようになります。MicroKernel エンジンでは、Get Position 要求を処理するためにディスク I/O は行われません。

Get Position オペレーションが正常に終了した場合は、MicroKernel エンジンからレコードの位置がデータ バッファーに返されます。位置はバイナリ値で、ファイル内におけるレコードのオフセットを示します。また、MicroKernel エンジンはデータ バッファー長を、BTRV タイプのエントリ ポイントの場合は 4 バイト、BTRVEX タイプのエントリ ポイントの場合は 8 バイトに設定します。

Get Position オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

Get Position オペレーションは、ポジショニングにまったく影響しません。

Get Previous オペレーション（B_GET_PREVIOUS）では、指定されたキーに基づいて、論理位置で前にあるレコードを取得します。Get Previous オペレーションを使うと、重複するキー値を持つレコードのグループの中でレコードを検索できます。Get Key（+50）バイアスを使うと、ファイル内に値が存在するかどうかを検出することもできます。一般に、Get Key オペレーションの方が高速に処理されます。

Get Previous オペレーションが正常に終了した場合、MicroKernel エンジンではキー バッファーが新しいレコードのキー値を使って更新され、データ バッファーに前のレコードが返され、データ バッファー長にそのレコードの長さが返されます。

Get Previous オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

このオペレーションの実行により、論理位置の直前がファイルの先頭よりも前を指す場合は、ステータス コード 9 が返されます。

Get Previous オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、取得したレコードが現在のレコードになります。

Get Previous Delete Extended オペレーション（B_GET_PREV_EXT_DELETE）では、指定されたキーに基づき、論理位置の直前からファイルの先頭へ向かって 1 つまたは複数のレコードを検索します。検索したレコードをフィルター条件と比較し、条件に一致するレコードを取得します。フィルター条件は論理式の形を取り、キー フィールドに限定されません。

このトピックで述べるように、このオペレーションが使用する入力および出力バッファー構造体、および返す結果は、Get Next Extended（36）に記載されているものと同じです。詳細については、当該オペレーションを参照してください。

Get Next Extended（36）の以下のトピックで、Extended オペレーションの入力バッファーの構造体とそのフィルター セグメントの使用について、さらに結果を返す出力バッファーの構造体について説明されています。

このオペレーションでは、Get Next Delete Extended（85）と同様の結果が返されます。詳細については、当該オペレーションを参照してください。

Get Previous Delete Extended オペレーションでは、カレンシーは確立しません。ただし、Get Next オペレーションまたは Get Previous オペレーションを実行することができ、次または前の論理位置は有効です。また、Get Position（22）および Get Direct/Record（23）を使用することにより、有効な現在の位置も使用可能になります。

次のリストは、選定されたステータス コードとフィルター条件の関係を示しています。

Get Previous Extended オペレーション（B_GET_PREV_EXTENDED）では、指定されたキーに基づき、論理位置の直前からファイルの先頭へ向かって 1 つまたは複数のレコードを検索します。検索したレコードをフィルター条件と比較し、条件に一致するレコードを取得します。フィルター条件は論理式の形を取り、キー フィールドに限定されません。

Get Previous Extended オペレーションでは、レコードから指定した部分だけを抽出し、その部分だけをアプリケーションに返すこともできます。

このトピックで述べるように、このオペレーションが使用する入力および出力バッファー構造体、および返す結果は、Get Next Extended（36）に記載されているものと同じです。詳細については、当該オペレーションを参照してください。

このオペレーションでは、Get Next Extended（36）の場合と同じ入力バッファーおよび出力バッファーを使用します。詳細については、当該オペレーションを参照してください。

このオペレーションでは、Get Next Extended（36）と同様の結果が返されます。詳細については、当該オペレーションを参照してください。

Get Previous Extended オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立されます。検索された最後のレコードが現在のレコードになります。このレコードは、フィルター条件を満たして取得されたレコードか、またはフィルター条件を満たさないために拒否されたレコードのいずれかです。

Insert オペレーション（B_INSERT）では、ファイルにレコードを挿入します。MicroKernel エンジンでは新しいレコードのキー値を反映して、キーの B ツリーが調整されます。

Insert オペレーションが正常に終了した場合、MicroKernel エンジンではファイルに新しいレコードが挿入され、新しいレコードを反映してキーの B ツリーが更新されます。また、指定したキーの値がキー バッファーに返されます。MicroKernel エンジンでは、autoincrement キーの値がバイナリ 0 に初期化されているレコードを挿入すると、挿入したレコードもデータ バッファーに返され、レコードには MicroKernel エンジンによって割り当てられた autoincrement 値が入っています。NCC Insert オペレーションでは、キー バッファー パラメーターの値は変更されません。

Insert オペレーションが失敗した場合は、MicroKernel エンジンから次のステータス コードのいずれかが返されます。

NCC オプションを指定しない Insert オペレーションを実行すると、完全な論理カレンシーおよび物理カレンシーが確立し、挿入したレコードが現在のレコードになります。論理カレンシーは指定したキーに基づきます。

NCC Insert オペレーションを実行すると、論理カレンシーは影響を受けずに、物理カレンシーが確立されます。つまり、NCC Insert オペレーションを実行したアプリケーションでは、ファイル内の論理位置は Insert オペレーションを実行する前と変わらないということです。このような状況で、NCC Insert オペレーションに続けて、Get Next（6）、Get Next Extended（36）、Get Previous（7）、および Get Previous Extended（37）などのオペレーションを実行すると、NCC Insert オペレーション実行以前のアプリケーションの論理カレンシーに基づく値が返されます。

MicroKernel エンジンでは標準の Insert オペレーションと NCC Insert オペレーションのどちらを実行しても、新しく挿入されたレコードに対し物理カレンシーが確立されます。NCC Insert オペレーションに続く Step Next（24）、Step Next Extended（38）、Step Previous（35）、Step Previous Extended（39）、Update（3）、Delete（4）、および Get Position（22）などのオペレーションは、新しい物理カレンシーに基づいて機能します。

Insert Extended オペレーション（B_EXT_INSERT）では、ファイルに 1 つまたは複数のレコードを挿入します。MicroKernel エンジンでは、新しいレコードのキー値を反映して、キーの B ツリーが調整されます。