ここでは、MicroKernelおよびリレーショナル エンジンを介して Zen によって提供される、データ型およびデータ型マッピングについて説明します。

次の表は、Zen によってサポートされるトランザクショナル データ型とリレーショナル データ型のマッピングです。Btrieve データ ファイルのデータにアクセスする SQL アプリケーションの開発者に有用です。

次の表は、Zen データ型で有効な値の範囲と、必要に応じてそれらに増分される値を示したものです。

式には複数の演算子が含まれることがあり、それらは優先順位に従って実行されます。Zen で使用される順序は次のとおりで、レベル 1 が最高、レベル 9 が最低です。高レベルの演算子は低レベルの演算子より先に評価されます。

式内にある同じ優先レベルの演算子は、左から右へ評価されます。たとえば、SET :Counter = 12 / 4 * 7 では、除算は乗算より先に評価され、結果として 21 が返されます。

かっこを使用すると、演算子の優先順位より優先させることができます。最初にかっこ内のものがすべて評価され、1 つの値がもたらされます。その後、この値がかっこの外にある演算子で使用されます。たとえば、次のステートメントの場合、除算演算子は通常は加算演算子より先に評価されます。結果は 12 になります（つまり、8 + 4）。しかし、加算はかっこで囲まれているため最初に実行されるので、プロシージャは結果の 4 を返します。

式にネストされたかっこがある場合は、一番深くネストされている式が最初に評価され、次に深くネストされている式の順に評価されます。たとえば、次のステートメントでは、加算が最初に実行され、次に乗算、減算、最後に除算が実行されます。結果は値 5 になります。

データ型の優先順位は、異なる型の 2 つの式が演算子によって結合されているときに、その結果の型を決定します。優先順位の低いデータ型は優先順位の高いデータ型に変換されます。

リレーショナルの数値データ型では次の優先順位を使用します。

リレーショナルの文字データ型では次の優先順位を使用します。

NCHAR または NVARCHAR と NLONGVARCHAR を連結させた場合、結果は NLONGVARCHAR になります。

NCHAR と LONGVARCHAR を連結させた場合、結果は NLONGVARCHAR になります。

CHAR または VARCHAR と LONGVARCHAR を連結させた場合、結果は LONGVARCHAR になります。

CHAR と VARCHAR を連結させた場合、結果の型はその連結で最初にくるデータ型になります。つまり左から右に移動します。たとえば、c1 が CHAR で c2 が VARCHAR の場合、（c1 + c2）の結果は CHAR になり、（c2 + c1）の結果は VARCHAR になります。

BINARY、LONGVARBINARY、および UNIQUEIDENTIFIER データ型の優先順位はありません。これらのデータ型を組み合わせる演算は許可されていません。

日付と時刻のデータ型は、他のどの日付または時刻のデータ型とも組み合わせることができません。

精度は、数値内の数字の数（桁数）です。小数位は、数値内の小数点より右側の数字の数です。たとえば、909.777 という数では精度が 6 で小数位が 3 となります。

NUMERIC、NUMERICSA、および DECIMAL データ型の最大精度は 64 です。NUMERICSTS および NUMERICSLS では、プラスまたはマイナス符号のために 1 バイトが予約されているため、最大精度は 63 です。

DECIMAL を除くすべての数値データ型で、精度と小数位は固定です。同じデータ型の 2 つの式で算術演算を行った場合、結果は同じデータ型となり、そのデータ型の精度と小数位を持ちます。データ型が異なる式で演算を行った場合は、優先順位のルールによって結果のデータ型が決定されます。結果の精度と小数位は、そのデータ型に定義されている桁数になります。

次の条件における演算の場合、結果は DECIMAL になります。

表 114 は、演算結果のデータ型が DECIMAL になる場合に精度と小数位を導き出す方法の定義を示しています。exp は「式」を表し、s は「小数位」、p は「精度」を表します。

たとえば、DECIMAL（8,2）および DECIMAL（7,4）と定義されている 2 つのフィールドを加算または減算した場合、結果フィールドは DECIMAL（11,4）になります。

タイムスタンプ データ型では、小数位はタイムスタンプ内の小数の秒部分の小数点より右側の桁数です。たとえば、2019-12-31 23:59:59.782 では小数位は 3 桁、つまりミリ秒となります。

Zen 14.10 から、TIMESTAMP データ型および TIMESTAMP2 データ型の小数位を選択できるようになりました。たとえば、次の SQL スクリプトは 4 つの列を持つテーブルを作成します。各列は TIMESTAMP または TIMESTAMP2 とし、最初の 2 列はデフォルトの小数位を持ち、次の 2 列は小数位を小数点以下 1 桁に設定しています。

SELECT ステートメントは次の行を返します。

小数位を短くした場合、小数の秒は丸められないことに留意してください。

次の表は、小数位を持つ日付およびタイムスタンプをサポートする Zen データ型の一覧を示します。

次の表は、小数位を持つ日付値およびタイムスタンプ値を返す Zen スカラー関数の一覧を示します。

関数から返されるタイムスタンプの小数位が、その値が書き込まれる列のデータ型の小数位より小さい場合、末尾の小数点以下桁数はゼロで埋められます。たとえば、CURRENT_TIMESTAMP() の値を TIMESTAMP2 列に入れるとした場合は、値 2019/12/10 14:23:46 292000000 が返されます。

アプリケーションが異なる SQL DBMS 製品に対して実行される場合は、切り捨てに関する以下の問題が発生する可能性があります。

特定の状況で、一部の SQL DBMS 製品では切り捨てのためにデータを挿入できないのに、Zen ではその同じデータを挿入できることがあります。さらに、Zen の SQL_SUCCESS_WITH_INFO のレポートと切り捨てられる情報は、メッセージが報告されるタイミングに基づく特定のシナリオにおいて、一部の SQL DMBS 製品と異なります。

数値文字列データおよび数値データは、Zen では常に切り捨てられるのに対し、SQL DBMS 製品では丸められます。たとえば、数値文字列または数値の 123.457 があり、これを 6 バイトの文字列の列または小数部 2 桁の数値列に挿入する場合、Zen は常に 123.45 を挿入します。これに対して、ほかの DBMS 製品は 123.46 という値を挿入することがあります。

このトピックでは、使用可能なデータ型に関するさまざまな動作およびキー情報について説明します。

LONGVARCHAR、NLONGVARCHAR、および LONGVARBINARY の制約も参照してください。

Zen では、1 つのテーブルで複数の LONGVARCHAR 列および LONGVARBINARY 列がサポートされます。データは、オフセットに応じてレコードの可変長部分に格納されます。データの可変長部分は、データの操作方法に応じて、データの列順とは異なるものにすることができます。次の例で考えてみましょう。

ディスク上では、物理レコードは通常次のように見えます。

列 Nbr を LONGVARCHAR 列に変更します。

これで、物理レコードはディスク上で次のように見えるようになりました。

見たとおり、データの可変長部分は既存のデータの列順には入りません。

しかし、新しく挿入したレコードについては、データの可変長部分は既存のデータの列順に入ります。これは、すべての列にデータが割り当てられている（列がヌルでない）ことを前提としています。

LONGVARCHAR、NLONGVARCHAR、および LONGVARBINARY の制約も参照してください。

LONGVARCHAR および LONGVARBINARY データ型には次の制約が適用されます。

DATETIME データ型は日付と時刻の値を表します。この型は、内部的に 2 つの 4 バイト整数として格納されます。最初の 4 バイトは基準日である 1900 年 1 月 1 日より前または後の日数を格納します。あとの 4 バイトは、深夜 0 時からのミリ秒数で表すその日の時刻を格納します。

DATETIME データ型はインデック付けすることができます。DATETIME の精度は 1 ミリ秒です。

DATETIME はリレーショナル データ型のみです。対応する Btrieve データ型はありません。

DATETIME の書式は YYYY-MM-DD HH:MM:SS.mmm のみです。ミリ秒部分を切り捨てる必要がある場合は、CONVERT 関数にそれを行うためのパラメーターがあります。次の表に、DATETIME のデータ コンポーネントとそれらの値の範囲を示します。

日付や時刻のデータ型を含む加算または減算を実行する必要がある場合は、スカラー関数の TIMESTAMPADD()、DATEADD()、TIMESTAMPDIFF()、および DATEDIFF() を使用することをお勧めします。式に新しい AUTOTIMESTAMP データ型および TIMESTAMP2 データ型が含まれている場合には、これらの関数の使用が必要になります。他のデータ型は、場合によっては演算子と共に式で直接使用できます。たとえば、次のステートメントは有効です。

クエリによっては、"互換性のない型" または "式にエラーがあります" というメッセージを返す可能性があります。たとえば、互換性のない値を加算または減算しようとするクエリや、結果が有効にならないクエリがこれに当たります。たとえば、次のステートメントはそのようなエラーを返します。

CONVERT 関数および CAST 関数は、次の表に示すように DATE、DATETIME、TIME、および TIMESTAMP と使用できます。

UNIQUEIDENTIFIER データ型は GUID（Globally Unique Identifier：グローバル一意識別子）として知られている 16 バイトのバイナリ値です。GUID は、行がほかの行と重複しない場合に有用です。

UNIQUEIDENTIFIER は、9.5 以降のファイル形式を必要とします。

UNIQUEIDENTIFIER の列またはローカル変数は、以下の方法で初期化できます。

引用符で囲んだ文字列を指定する場合、32 桁全部を指定する必要があります。データベース エンジンは部分文字列の埋め込み処理を行いません。

以下の比較演算子のみが UNIQUEIDENTIFIER に使用できます。

2 つの値のビット パターンの比較によっては並べ替えは行われません。

SET ステートメントを使用して UNIQUEIDENTIFIER データ型の変数を宣言することができます。

UNIQUEIDENTIFER は CAST または CONVERT スカラー関数使用して以下のデータ型のいずれかに変換できます。

変換の例については、変換関数を参照してください。

Zen で無限を表すには、次の表のように、4 バイト（C 言語の float 型）または 8 バイト（C 言語の double 型）の形式で、16 進数または文字として表現できます。

いくつかの古い（レガシー）データ型は、現行リリースの Zen ではサポートされていません。次の表は、旧データ型に代わって使用する新データ型を示します。

上記のデータ型を使用している既存のデータベースはサポートされており、正しく機能します。新しいデータベースでは旧形式のデータ型を持つテーブルを作成することはできません。ただし、IN DICTIONARY 句を使用して、新しいデータベースの DDF に旧データ型を持つテーブルを追加することはできます。CREATE TABLE を参照してください。

このトピックでは、インデックスを作成できる Btrieve データ型（キー タイプ）について説明します。MicroKernel は内部的に、文字列キーを 1 バイトずつ左から右へ比較します。デフォルトで、MicroKernel は ASCII 値に基づいて文字列キーをソートします。しかし、文字列キーは、大文字小文字を無視したり、オルタネート コレーティング シーケンス（ACS）を使用するように定義することもできます。

MicroKernel は、符号なしバイナリ キーを一度に 1 WORD ずつ比較します。Intel 8086 プロセッサ ファミリは Integer の上位バイトと下位バイトを反転させるため、MicroKernel はこれらのキーを右から左へ比較します。

特定のデータ型が複数のサイズで使用できる（たとえば、4 バイトと 8 バイトの FLOAT 値が使用できる）場合は、（新しいキーの作成に使用される）キー長パラメーターにより、そのキーのすべての値に適用されるサイズが定義されます。許可されていないキーの長さを使ってキーを定義しようとすると、ステータス 29（キー長が不正）になります。

次の表は、キー タイプとそれに関連付けられたコードの一覧を示します。表に続いて、各キー タイプの内部記憶形式について説明します。

AUTOINCREMENT キー タイプは、2 バイト、4 バイト、または 8 バイト長の符号付き Intel 整数です。autoincrement キーは、内部的に Intel バイナリ整数形式で格納され、WORD 内で上位バイトと下位バイトが反転されています。MicroKernel は autoincrement キーをその絶対値を基に、右から左へと一度に 1 WORD ずつ別のレコードに保存されている値と比較してソートします。autoincrement キーを使用すると、ファイルにレコードを挿入するとき、既存の最大の値より 1 大きい値を自動的に割り当てることができます。値は絶対値を基にソートされるため、データ型が符号付きと考えた場合、可能性のあるレコード数は期待するレコード数のおおよそ半分になります。

ファイルから削除された値は、自動的には再使用されません。挿入または更新でゼロ（0）値を入力したら次に来る値を割り当てるようにデータベース エンジンに指示している場合、データベースは単純に最も大きい値を調べ、その値に 1 を足した結果を挿入します。

すべてのレコードまたは一部のレコードで 1 つのフィールドの値を 0 に初期化し、後から AUTOINCREMENT タイプのインデックスを追加できます。この機能により、必要になるまで実際にインデックスを作成しなくても autoincrement キーの準備をすることができます。

インデックスを追加すると、MicroKernel は各フィールドの 0 値を適切に変更します。値の番号付けは、そのフィールドで現在定義されている最大値に 1 を足した値から始まります。フィールドに 0 以外の値が存在する場合、MicroKernel はそれらを変更しません。ただし、0 以外の重複する値がフィールドに存在する場合は、MicroKernel はエラー ステータス コードを返します。

MicroKernel は、autoincrement キーを含んでいる各オープン ファイルに関連付けられる自動インクリメント値の、以前に使用した最大値を保持します。この値は、autoincrement フィールドに ASCII ゼロを含むレコードについて INSERT オペレーションが発生した場合にのみ、確立されて増加します。キー ページの並行性を利用して同時変更が行えるように、値はすべてのクライアントから使用されます。

ファイルの次の autoincrement 値は、前の autoincrement 値を使った INSERT が発生するたびに増加されます。これは、INSERT がトランザクション内にあるかどうか、また変更がコミットされるかどうかに関係なく起こります。

ただし、以下の項目がすべて真の場合には、INSERT 中にこの値を小さくすることができます。

つまり、1 トランザクション内の最初の INSERT のみが、次回使用可能な autoincrement 値を小さくすることができます。その後、次回使用可能な autoincrement 値は増加し続けます。

例を示して、autoincrement 値を小さくできる方法をわかりやすくしましょう。レコード 1、2、3 および 4 を含む自動インクリメント ファイルがあるとします。次回使用可能な autoincrement 値は 5 です。

クライアント1 がトランザクションを開始し、新しいレコードを 2 件挿入すると、次回使用可能な autoincrement 値は 7 に増えます（クライアント1 は値 5 と 6 を取得します）。クライアント2 がトランザクションを開始し、また新しいレコードを 2 件挿入します。これにより、次回使用可能な autoincrement 値は 9 に増えます（クライアント2 は値 7 と 8 を取得します）。

クライアント1 がレコード 4、5、6 を削除します。次回使用可能な autoincrement 値は INSERT でしか調整されないので、同じ値のままです。次に、クライアント1 がコミットを行います。コミットされたバージョンのファイルには、現在レコード 1、2 および 3 が含まれています。

クライアント2 の場合、ファイルにはレコード 1、2、3、7 および 8 が含まれます（7 と 8 はまだコミットされていません）。次にクライアント2 がもう 1 件レコードを挿入すると、レコード 9 になり、次回使用可能な autoincrement 値は 10 に増えます。クライアント2 がレコード 3、7、8、9 を削除します。クライアント2 では、現在ファイルにはコミット済みのレコード 1 と 2 だけが含まれています。

次にクライアント2 がもう 1 件レコードを挿入すると、レコード 10 になります。次回使用可能な autoincrement 値は 11 に増えます。この値は、変更を含んでいるページに保留状態のほかの変更があるため、3 に減らされません。

次に、クライアント2 がトランザクションを中止します。コミットされたバージョンのファイルには、現在レコード 1、2 および 3 が含まれていますが、次回使用可能な autoincrement 値は 11 のままです。

どちらかのクライアントが、トランザクションの内外を問わずもう 1 件レコードを挿入すると、次回使用可能な autoincrement 値は 4 に減少されます。これは、値を小さくするのに必要な条件がすべて真であるために起こります。

自動インクリメントした値が範囲外になる場合は、ステータス コード 5 が返されます。データベース エンジンは、値の「折り返し」を試みることも、再度ゼロから始めることもしません。ただし、以前に挿入した値が削除されており、自動インクリメントのシーケンス中で欠番になっている箇所がわかる場合は、未使用値を直接挿入することができます。

AUTOINCREMENT 型のキーには次の制限が適用されます。

ファイルにレコードを挿入すると、MicroKernel は autoincrement キー値を次のように扱います。

AUTOTIMESTAMP キー タイプは 8 バイトの符号なし整数で、Unix エポックに基づいてナノ秒単位で時間を追跡します。値 0 は、新しいレコードが挿入されたとき、または既存のレコードが初めて更新されたときに、この値を自動的に現在の時刻に置き換えるよう、データベース エンジンに指示します。0 以外の値も指定でき、その場合は 1970 UTC からのナノ秒数として解釈されます。

このキー タイプを利用できるのは Zen v14 からで、対象となるファイル形式は 9.5 から 13.0 です。古いデータベース エンジンで、このタイプを使用するレコードを持つファイルを開こうとすると、認識されない Microkernel ファイルに対するステータス コード 30 が返されます。

AUTOTIMESTAMP 値の範囲は、1970-01-01 00:00:00.000000000 ～ 2554-07-21 23:34:33.709551615 です。

現在の Linux および Android のシステム時計は、真のナノ秒の精度を備えています。Windows では、最も高い精度はセプタ秒（10-7 秒）で、macOS ではマイクロ秒です。ナノ秒の精度に対応していないシステム上で AUTOTIMESTAMP キーが書き込まれた場合、値はゼロで埋められます。その結果、ナノ秒精度でないシステムで挿入または更新を行うと、値が重複する可能性があります。しかし、インデックスが一意となるよう設定されている場合には、データベース エンジンは、以前に生成された最新のタイムスタンプとの一致を検出すると、1 ナノ秒を加算します。重複は、手動で挿入されたタイムスタンプ値や、システム時計のリセットによっても生じる可能性があります。どちらの場合も、Insert（2）または Update（3）はステータス コード 5 で失敗します。

Insert（2）および Update（3）オペレーションは、AUTOTIMESTAMP キーのゼロ値を処理する場合、データベース エンジン サーバーのシステム時計から現在のタイムスタンプを取得します。エンジンは、現在のレコード内で、ゼロを含むすべての AUTOTIMESTAMP キーに対してこの値を使用します。

Insert Extended（40）の場合は、エンジンはオペレーション内で指定されたレコードごとに新しいタイムスタンプ値を取得します。AUTOTIMESTAMP キーを一意とした場合、その値が同一オペレーション内で以前に生成されたタイムスタンプ値と一致する場合には、生成された値を 1 ナノ秒ずつ加算することで、レコード間でタイムスタンプが重複しないようにします。Insert（2）と同様に、レコードごとに生成されるタイムスタンプは、当該レコード内のすべての AUTOTIMESTAMP キーに使用されます。

Update Chunk（53）オペレーションで、AUTOTIMESTAMP キーを含むレコードの固定部分に書き込みを行う場合、エンジンは新しいタイムスタンプを取得しません。代わりに、提供されたキー値をそのまま受け入れ、レコードにセットします。したがって、Update Chunk オペレーションを使用するときに、AUTOTIMESTAMP キーを更新するためにゼロ値を指定すると、レコードにゼロ値が格納され、キーは 1970 UTC と解釈されることになります。自動生成されたタイムスタンプでキーを更新したい場合は、Update（3）オペレーションを使用してレコードの固定部分を更新します。

AUTOTIMESTAMP 型のキーを作成する場合には、次の制限が適用されます。

Function Executor ツールまたは Maintenance ツールでの AUTOTIMESTAMP キーの使い方は、AUTOINCREMENT キーと似ています。このキーを使用するファイルの場合、キー タイプは Atstamp として一覧に表示されます。また、Atstamp は butil <filename> -stat の出力に表示され、butil -create コマンドのディスクリプション ファイルのキー タイプに使用されます。

倍精度実数の表現法は、仮数が 23 ビットではなく 55 ビットである点を除いては、単精度実数の表現法と同じです。最小有効数字の 32 ビットは、バイト 0 から 3 に格納されます。

BFLOAT 型は、一般に古い BASIC アプリケーションで使用されます。Microsoft はこのデータ型を MBF（Microsoft Binary Format）と呼びますが、Visual Basic 環境でこの型はサポートしていません。新しいデータベース定義では、BFLOAT ではなく FLOAT を使用する必要があります。

STRING キー タイプは、左から右へ並んだ文字の連なりです。キー値がヌルであるかどうかを MicroKernel が判定する場合を除いて、各文字は単一バイトに ASCII 形式で表されます。STRING データは、キーのサイズいっぱいになるまで空白を埋め込む必要があります。

CURRENCY キー タイプは、8 バイトの符号付き数値を表し、Intel バイナリ整数形式で並べ替えられ格納されています。このため、その内部表現法は 8 バイトの INTEGER データ型と同じです。CURRENCY データ型には、小数点以下に 4 桁が想定されており、通貨のデータ値の分数部分を表します。

日付フィールドに使用する C 言語の構造体の例を示します。

日付フィールドの year 部には、年全体の整数表現が設定されるようにする必要があります。たとえば、2001 年の場合は 2,001 です。

DECIMAL の小数点は暗黙に設定されます。DECIMAL フィールドに小数点は格納されません。DECIMAL フィールドの値の小数点位置のトラッキングはアプリケーションが行います。データベース エンジンがキーを正しく照合するために、DECIMAL キー タイプの値はすべて、小数点以下の桁数を同じにする必要があります。DECIMAL 型は、一般に COBOL アプリケーションで使用されます。

8 バイトの decimal は、15 桁の数字と符号を保持することができます。10 バイトの decimal では、19 桁の数字と符号を保持できます。decimal 値は、左側の桁をゼロで埋める必要があります。

符号ニブルは、正の数の場合は 0xF または 0xC で、負の数の場合は 0xD です。デフォルトで、リレーショナル エンジンおよびそれを使用する SDK アクセス方法の場合、DECIMAL 用の正符号ニブルには常に 0xF を書き込みます。これらは読み取りオペレーションに対し 0xF および 0xC の両方を正として解釈することができます。

レジストリ（Windows レジストリおよび Zen レジストリ）の設定によって、DECIMAL 用の正符号のニブルに対してどのデータベース エンジンを使用するか制御します。デフォルトの正符号ニブルを 0xC に変更する必要がある場合、下記のようにレジストリを編集します。Zen ActiveX アクセス方法では、CommonCOBOLDecimalSign のレジストリ設定に関わらず、正符号ニブルに 0xF を必ず使用することに留意してください。

レジストリ エディターで、次のキーの CommonCOBOLDecimalSign の値を "YES" に変更します。

HKEY_LOCAL_MACHINE\SOFTWARE\Actian\Zen\SQL Relational Engine

ほとんどの Windows システムで、このキーの場所は HKEY_LOCAL_MACHINE\SOFTWARE\Actian\Zen です。ただし、HKEY_LOCAL_MACHINE\SOFTWARE の下位以降の場所はオペレーティング システムによって異なる可能性があります。

Linux 32 ビット オペレーティング システムの場合、psregedit ユーティリティは次のように指定して実行します。

Linux および macOS 64 ビット オペレーティング システムの場合、psregedit ユーティリティは次のように指定して実行します。

『Zen User's Guide』の psregedit も参照してください。

GUID キー タイプは 16 バイトの数字で、内部的には 16 バイトのバイナリ値として格納されます。拡張データ型の値は 27 です。

通常、GUID はグローバルな一意識別子として使用されます。これはリレーショナル エンジンの UNIQUEIDENTIFIER データ型に相当します。

GUID は 9.5 以降のファイル形式を必要とすることに注意してください。

GUID を構成するバイトのソート順序は、10、11、12、13、14、15、8、9、6、7、4、5、0、1、2、3 という順序で比較されます。

GUID のキー セグメント長は 16 バイトにする必要があります。『Btrieve API Guide』のキー仕様ブロックを参照してください。

INTEGER キー タイプは、符号付き整数で、偶数バイトを保持する必要があります（1 は例外）。何桁の数字でも含むことができます。INTEGER フィールドは、内部的に Intel バイナリ整数形式で格納され、WORD 内で上位バイトと下位バイトが反転されています。MicroKernel は、キーを右から左へと一度に 1 WORD ずつ評価します。符号は、右端のバイトの上位ビットに格納しなければなりません。INTEGER 型は、ほとんどの開発環境でサポートされています。

LOGICAL キー タイプは、1 バイト値または 2 バイト値として格納されます。MicroKernel は LOGICAL キー タイプを文字列として照合します。これにより、アプリケーションは、格納されている真または偽を表す値を判定することができます。

LSTRING キー タイプは、文字列の最初のバイトに文字列の長さのバイナリ表現を含む点を除いて、通常の STRING 型と同じ特性を持ちます。LSTRING キー タイプのサイズは、最大 255 バイトに制限されています。LSTRING キーのバイト 0 に格納されている長さにより、有効バイト数が判断されます。データベース エンジンは、値をソートまたは検索する際、指定された文字列の長さを超える値はすべて無視します。LSTRING 型は、一般に古い Pascal アプリケーションで使用されます。

MONEY キー タイプの内部表現法は DECIMAL 型と同じですが、小数点以下が 2 桁に想定されます。

NUMERIC キー タイプの数字はそれぞれ 1 バイトを占めます。NUMERIC 値は、先頭に 0 を付けて右揃えされ、ASCII 文字列として格納されます。右端のバイトには、埋め込み符号が EBCDIC 値で含まれます。デフォルトで、正の NUMERIC データ型の符号値は符号なし数値です。

オプションで、正の NUMERIC データ型の符号の値をシフトするよう指定できます。次の表は、符合値のデフォルト（シフトされていない）状態とシフトされた状態の比較を示します。

シフト形式を有効にするには、Zen データベース エンジンが実行されているマシンで、ある設定を手動で指定しなければなりません。設定 DBCobolNumeric を yes にセットします。このトピックでは、Windows 32 ビット、Linux、および macOS プラットフォームでのこの設定の使用について概説します。

レジストリ エディターを使用して、DBCobolNumeric 設定を次のキーの文字列値として追加します。

HKEY_LOCAL_MACHINE\SOFTWARE\Actian\Zen\Database Names

DBCobolNumeric の文字列値を yes に設定します。

ほとんどの Windows システムで、このキーの場所は HKEY_LOCAL_MACHINE\SOFTWARE\Actian\Zen ですが、HKEY_LOCAL_MACHINE\SOFTWARE の下位以降の場所はオペレーティング システムによって異なります。

データベース エンジンまたはエンジン サービスを停止して、再起動します。

bti.ini の [Database Names] エントリの下に DBCobolNumeric 設定を追加します。

デフォルトでは、bti.ini は /usr/local/actianzen/etc ディレクトリにあります。

データベース エンジンを停止して、再起動します。

符合値がデフォルト（シフトされていない）形式で含まれている正の NUMERIC データが既にあるかもしれません。DBCobolNumeric を yes に設定した後、引き続き同じテーブルへデータを追加すると、形式が混在することになります。データの符合値の形式を混在させたままにしておくことはお勧めできません。

形式が混在した状態を解消する、あるいは防ぐには、UPDATE ステートメントを使用して、NUMERIC 列をその列自身で更新します。たとえば、テーブル t1 には NUMERIC データ型の列 c1 があるとします。DBCobolNumeric を yes に設定後、c1 を UPDATE TABLE t1 SET c1 = c1 のように更新します。

NUMERICSA キー タイプ（NUMERIC SIGNED ASCII と呼ばれることもあります）は、COBOL データ型で、埋め込み符号が EBCDIC 値ではなく ASCII 値である点を除けば、NUMERIC と同じです。

NUMERICSLB キー タイプ（SIGN LEADING と呼ばれることもあります。COBOL コンパイラ オプション -dcb を使用します）は、COBOL データ型で、NUMERIC データ型の値と似た値を持ちます。NUMERICSLB 値は、先頭に 0 を付けて右揃えされ、ASCII 文字列として格納されます。

NUMERICSLS キー タイプ（SIGN LEADING SEPARATE と呼ばれることもあります）は、COBOL データ型で、NUMERIC データ型の値と似た値を持ちます。NUMERICSLS 値は、先頭に 0 を付けて左揃えされ、ASCII 文字列として格納されます。ただし、NUMERICSLS 文字列の左端のバイトは、「+」（ASCII 0x2B）か「-」（ASCII 0x2D）のいずれかになります。この点が、右端のバイトにそのバイトの値と共に符号を埋め込む NUMERIC 値とは異なります。

NUMERICSTB キー タイプ（SIGN TRAILING と呼ばれることもあります。COBOL コンパイラ オプション -dcb を使用します）は、COBOL データ型で、NUMERIC データ型の値と似た値を持ちます。NUMERICSTB 値は、先頭に 0 を付けて右揃えされ、ASCII 文字列として格納されます。

NUMERICSTS キー タイプ（SIGN TRAILING SEPARATE と呼ばれることもあります）は、COBOL データ型で、NUMERIC データ型の値と似た値を持ちます。NUMERICSTS 値は、先頭に 0 を付けて右揃えされ、ASCII 文字列として格納されます。ただし、NUMERICSTS 文字列の右端のバイトは、「+」（ASCII 0x2B）か「-」（ASCII 0x2D）のいずれかになります。この点が、右端のバイトにそのバイトの値と共に符号を埋め込む NUMERIC 値とは異なります。

TIMESTAMP キー タイプは日付と時刻の値を表します。SQL アプリケーションでは、このデータ型を使用して、レコードを最後に更新した現在の日時をレコードにスタンプします。TIMESTAMP 値は、グレゴリオ暦 0001 年 1 月 1 日の世界協定時刻（UTC）から経過したセプタ秒（10^-7 秒）を表す、8 バイトの符号なし値として格納されます。サポートされる値の範囲は、0001-01-01 00:00:00.0000000 ～ 9999-12-31 23:59:59.9999999 です。

AUTOTIMESTAMP とは異なり、値 0 は、新しいレコードが挿入されたとき、または既存のレコードが初めて更新されたときの現在の時刻に自動的に置き換えられません。

TIMESTAMP は、構成要素、年、月、日、時、分、秒、およびミリ秒から成る日付と時刻の値をサポートします。次の表は、これらの各構成要素で有効な値の範囲を示しています。

各 TIMESTAMP 値は完全な日付時刻の値を含んでいます。小数位はローカル オペレーティング システムでサポートされる最大の桁数を持ち、必要に応じて末尾のゼロで埋められます。値が返されるとき、この値はタイムスタンプに対して設定された小数位を使用します。たとえば、小数位が 3 の場合はマイクロ秒で返され、小数位が 6 の場合はミリ秒で返されます。

日付データ型および時刻データ型の小数位の詳細については、タイムスタンプ データ型の小数位と返される関数値を参照してください。

現地時刻で TIMESTAMP の値を指定すると、リレーショナル エンジンはそれを UTC（Coordinated Universal Time）に変換してからレコードに格納します。TIMESTAMP 値を要求すると、リレーショナル エンジンは値を現地時刻に変換して返します。

タイムスタンプ データは格納する前に変換されるため、TIMESTAMP 型は、データベース本体の外にあるイベントを参照する現地時刻データや現地日付データでの使用には向きません。特に、季節時間の変更が行われるタイム ゾーン（米国のサマー タイムなど）ではそうです。

たとえば、10 月 15 日に、11 月 15 日午前 10 時の予定を記録するタイムスタンプ値を入力したとします。タイム ゾーンは U.S. 中部であるとします。リレーショナル エンジンは値を格納するとき、現在の現地時刻情報を使って値を UTC に変換します（CDT の場合、UTC - 5 時間）。したがって、時間値 15 が格納されます。11 月 1 日に予定の時刻を確認するとします。現在、お使いのコンピューターは標準時間になっています。これは、10 月にサマー タイムの切り替えが発生したためです。これにより、変換は（UTC - 6 時間）になります。予定時刻を抽出すると、現地時刻の午前 9 時（15 UTC - 6 CST）が表示されますが、これは正しい予定時刻ではありません。

データベース エンジンをあるタイム ゾーンから別のタイム ゾーンに移動させた場合も、同種の問題が発生します。

リレーショナル エンジンは、DATE 値および TIME 値を UTC に変換しないので、外部データを記録する場合は、できる限りいつも DATE 列および TIME 列を使用することをお勧めします。TIMESTAMP 列を使用する唯一の理由は、データベースに入力したレコードの時間順を判定する固有の機能に必要だからです。

Function Executor ツールまたは Maintenance ツールでの TIMESTAMP キーの使い方は、AUTOINCREMENT キーと似ています。このキーを使用するファイルの場合、キー タイプは Tstamp として一覧に表示されます。また、Tstamp は butil <filename> -stat の出力に表示され、butil -create コマンドのディスクリプション ファイルのキー タイプに使用されます。

TIMESTAMP2 キー タイプは、Unix エポックに基づいてナノ秒単位で時間を追跡します。SQL アプリケーションでは、このデータ型を使用して、レコードを最後に更新した現在の日時をレコードにスタンプします。値は、グレゴリオ暦 1970 年 1 月 1 日の世界協定時刻（UTC）から経過したナノ秒（10^-9 秒）を表す、8 バイトの符号なし値として格納されます。サポートされる値の範囲は、1970-01-01 00:00:00.000000000 ～ 2554-07-21 23:34:33.709551615 です。

AUTOTIMESTAMP とは異なり、値 0 は、新しいレコードが挿入されたとき、または既存のレコードが初めて更新されたときの現在の時刻に自動的に置き換えられません。

このキー タイプを利用できるのは Zen v14 SP1 からで、対象となるファイル形式は 9.5 から 13.0 です。古いデータベース エンジンで、このタイプを使用するレコードを持つファイルを開こうとすると、認識されない Microkernel ファイルに対するステータス コード 30 が返されます。

TIMESTAMP2 は、構成要素、年、月、日、時、分、秒、およびナノ秒から成る日付と時刻の値をサポートします。次の表は、これらの各構成要素で有効な値の範囲を示しています。

各 TIMESTAMP2 値は完全な日付時刻の値を含んでいます。小数位はローカル オペレーティング システムでサポートされる最大の桁数を持ち、必要に応じて末尾のゼロで埋められます。値が返されるとき、この値はタイムスタンプに対して設定された小数位を使用します。たとえば、小数位が 3 の場合はマイクロ秒で返され、小数位が 6 の場合はミリ秒で返されます。

日付データ型および時刻データ型の小数位の詳細については、タイムスタンプ データ型の小数位と返される関数値を参照してください。

現地時刻で TIMESTAMP2 の値を指定すると、リレーショナル エンジンはそれを UTC（Coordinated Universal Time）に変換してからレコードに格納します。TIMESTAMP2 値を要求すると、リレーショナル エンジンは値を現地時刻に変換して返します。

タイムスタンプ データは格納する前に変換されるため、TIMESTAMP2 型は、データベース本体の外にあるイベントを参照する現地時刻データや現地日付データでの使用には向きません。特に、季節時間の変更が行われるタイム ゾーン（米国のサマー タイムなど）ではそうです。

たとえば、10 月 15 日に、11 月 15 日午前 10 時の予定を記録するタイムスタンプ値を入力したとします。タイム ゾーンは U.S. 中部であるとします。リレーショナル エンジンは値を格納するとき、現在の現地時刻情報を使って値を UTC に変換します（CDT の場合、UTC - 5 時間）。したがって、時間値 15 が格納されます。11 月 1 日に予定の時刻を確認するとします。現在、お使いのコンピューターは標準時間になっています。これは、10 月にサマー タイムの切り替えが発生したためです。これにより、変換は（UTC - 6 時間）になります。予定時刻を抽出すると、現地時刻の午前 9 時（15 UTC - 6 CST）が表示されますが、これは正しい予定時刻ではありません。

データベース エンジンをあるタイム ゾーンから別のタイム ゾーンに移動させた場合も、同種の問題が発生します。

リレーショナル エンジンは、DATE 値および TIME 値を UTC に変換しないので、外部データを記録する場合は、できる限りいつも DATE 列および TIME 列を使用することをお勧めします。TIMESTAMP2 列を使用する唯一の理由は、データベースに入力したレコードの時間順を判定する固有の機能に必要だからです。

Function Executor ツールまたは Maintenance ツールでの TIMESTAMP2 キーの使い方は、AUTOINCREMENT キーと似ています。このキーを使用するファイルの場合、キー タイプは TS2 として一覧に表示されます。また、TS2 は butil <filename> -stat の出力に表示され、butil -create コマンドのディスクリプション ファイルのキー タイプに使用されます。

UNSIGNED BINARY キーは、キーの最大長である 255 バイトまでであれば何バイトにでもできます。UNSIGNED キーは、上位バイトから下位バイトへと 1 バイトごとに比較されます。キーの最初のバイトが下位バイトです。キーの最後のバイトが上位バイトです。

データベース エンジンは、UNSIGNED BINARY キーを符号なしの INTEGER キーとしてソートします。これらのキーの違いは、INTEGER には符号ビットがあるのに対し、UNSIGNED BINARY タイプにはないという点と、UNSIGNED BINARY キーは 4 バイトより長くすることができるという点です。

WSTRING は、ヌルで終わらない Unicode 文字列です。文字列の長さはフィールドの長さで決まります。

WZSTRING は、2 つのヌルで終わる Unicode 文字列です。文字列の長さは、フィールド内の Unicode NULL（2 ヌル バイト）の位置で決まります。これは、Btrieve でサポートされる ZSTRING 型に対応します。

ZSTRING キー タイプは、C 文字列に対応します。ZSTRING 型は、バイナリ 0 を含むバイトで終わるという点以外は、通常の文字列型と同じ特性を持ちます。MicroKernel は、キー値がヌルかどうかを判定する場合を除き、ZSTRING 内で見つけた最初のバイナリ 0 より後の値をすべて無視します。

ZSTRING 型の最大長は、ヌル終端文字を含めて、255 バイトです。ヌル値を許可する列のキーとして使用する場合、文字列の先頭 254 バイトのみがキーに使用されます。このわずかな制限は、キーの合計長が 255 バイトに制限されていることにより生じるもので、1 バイトは列のヌル インジケータが占めるため、残り 254 バイトだけがキー値になります。

このトピックでは、インデックスを設定できない（Btrieve キーとして使用できない）データ型の内部記憶形式について説明します。

バイナリ ラージ オブジェクト（BLOB）タイプは、最大 2 GB までのサイズのバイナリ データ フィールドのサポートを提供します。このタイプは 2 つの部分から成ります。

詳細については、BINARY および LONGVARBINARY、LONGVARCHAR、NLONGVARCHAR、および LONGVARBINARY の制約を参照してください。

文字ラージ オブジェクト（CLOB）タイプは、最大 2 GB までのサイズの文字列データ フィールドのサポートを提供します。このタイプは 2 つの部分から成ります。

詳細については、CHAR、NCHAR、VARCHAR、NVARCHAR、LONGVARCHAR、および NLONGVARCHAR、LONGVARCHAR、NLONGVARCHAR、および LONGVARBINARY の制約を参照してください。