データ型

データ型	デフォルトの小数位を含む形式	小数位
AUTOTIMESTAMP	yyyy-mm-dd hh:mm:ss.nnnnnnnnn（ナノ秒）	9
DATETIME	yyyy-mm-dd hh:mm:ss.nnn（ミリ秒）	3
TIMESTAMP	yyyy-mm-dd hh:mm:ss.nnn（ミリ秒）	3
TIMESTAMP(n)	yyyy-mm-dd hh:mm:ss.nnnnnnn（なし～セプタ秒）	0-7
TIMESTAMP2	yyyy-mm-dd hh:mm:ss.nnnnnnnnn（ナノ秒）	9
TIMESTAMP2(n)	yyyy-mm-dd hh:mm:ss.nnnnnnnnn（なし～ナノ秒）	0-9

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

関数	形式	小数位
CURRENT_TIMESTAMP()	yyyy-mm-dd hh:mm:ss.nnn（ミリ秒）	3
NOW()	yyyy-mm-dd hh:mm:ss.nnn（ミリ秒）	3
SYSDATETIME()	yyyy-mm-dd hh:mm:ss.nnnnnnnnn（ナノ秒）	9
SYSUTCDATETIME()	yyyy-mm-dd hh:mm:ss.nnnnnnnnn（ナノ秒）	9

関数から返されるタイムスタンプの小数位が、その値が書き込まれる列のデータ型の小数位より小さい場合、末尾の小数点以下桁数はゼロで埋められます。たとえば、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 という値を挿入することがあります。

データ型に関する注意事項

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

CHAR、NCHAR、VARCHAR、NVARCHAR、LONGVARCHAR、および NLONGVARCHAR

•

CHAR および NCHAR 列には、末尾の空白が埋め込まれます。比較演算（LIKE および =）では、このような空白は演算の対象になりません。ただし、LIKE の場合、クエリに空白が明示的に入力されているとき（'abc %' など）は、ワイルドカードの前の空白は演算の対象になります。この例の場合、'abc<空白><任意の文字>' を検索します。

•

CHAR 型は、データベースコードページを使用して、つまり、1 文字につき 1 バイト以上を使用して文字を格納します。NCHAR 型は、UCS-2 の 2 バイト値として文字を格納します。

•

VARCHAR、NVARCHAR、LONGVARCHAR、および NLONGVARCHAR 値は末尾の空白は埋め込まれません。意味のあるデータはヌル文字で終わります。

•

VARCHAR および NVARCHAR の比較演算子では、末尾の空白は意味を持ちます。たとえば c1 = 'Test ' とした場合、c1 が VARCHAR 型であるとき、値 'Test' を含む列は検出されません。

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

BINARY および LONGVARBINARY

•

BINARY 列には、末尾のゼロが埋め込まれます。

•

LONGVARBINARY 列には、末尾のゼロは埋め込まれません。

•

データベースエンジンは、LONGVARBINARY 列の比較はできません。データベースエンジンは、固定長の BINARY データの比較はできます。

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

CREATE TABLE BlobDataTest

(

Nbr UINT, // 固定レコード (型 14)

Clob1 LONGVARCHAR, // 固定レコード (型 21)

Clob2 LONGVARCHAR, // 固定レコード (型 21)

Blob1 LONGVARBINARY, // 固定レコード (型 21)

)

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

[固定データ (Nbr, Clob1header, Clob2header, Blob1header)][ClobData1][ClobData2][BlobData1]

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

ALTER TABLE BlobDataTest ALTER Nbr LONGVARCHAR

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

[固定データ (Nbrheader, Clob1header, Clob2header, Blob1header)][ClobData1][ClobData2][BlobData1]
[NbrClobData]

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

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

[固定データ (Nbrheader, Clob1header, Clob2header, Blob1header)][NbrClobData][ClobData1][ClobData2]
[BlobData1]

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

LONGVARCHAR、NLONGVARCHAR、および LONGVARBINARY の制約

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

•

LIKE 述部は、列データの最初の 65500 バイトに適用されます。

•

その他の述部はすべて、列データの最初の 256 バイトに適用されます。

•

GROUP BY、DISTINCT、および ORDER BY を伴った SELECT ステートメントはすべてのデータを返しますが、列データの最初の 256 バイトにのみ指示を行います。

•

LONGVARCHAR および LONGVARBINARY 型の列には最大 2 GB までデータを挿入できますが、INSERT ステートメントでリテラル値を使用すると、挿入可能なバイト数は 15000 に減ります。ただし、パラメーター化された INSERT を使用することによって、15000 バイト以上挿入することは可能です。

•

Zen による 1 回の呼び出しで、LONGVARCHAR、NLONGVARCHAR、または LONGVARBINARY 列に対して返される最大のバイト数は、アプリケーションが使用するアクセス方法によって異なります。ほとんどの場合、この制限は 65500 バイトです。詳細については、特定の開発環境用のドキュメントを参照してください。

DATETIME

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

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

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

DATETIME の書式

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

コンポーネント	有効な値
Year（YYYY）	1753 ～ 9999
Month（MM）	01 ～ 12
Day（DD）	01 ～ 31
Hour（HH）	00 ～ 23
Minute（MM）	00 ～ 59
Second（SS）	00 ～ 59
Millisecond（mmm）	000 ～ 999

日付と時刻のデータ型の互換性

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

SELECT "Start_Date" + 5 FROM "Class"

SELECT "Finish_Time" – "Start_Time" FROM "Class"

SELECT current_timestamp() – "Log" FROM "Billing"

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

SELECT "Start_Date" + 5.0 FROM "Class"

SELECT "Start_Time" + "Finish_Time" FROM "Class"

SELECT current_timestamp() + "Log" FROM "Billing"

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

表 115

SQL_CHAR、SQL_DATE、SQL_TIME、SQL_TIMESTAMP、SQL_VARCHAR

DATE

SQL_CHAR、SQL_DATE、SQL_TIMESTAMP、SQL_VARCHAR

DATETIME

GUID、BINARY、および LONGVARBINARY 以外の、サポートされる CONVERT データ型。CONVERT の type パラメーターには、プレフィックス "SQL_" が必要です。CONVERT(exp, type[, style ]) を参照してください。

TIME

SQL_CHAR、SQL_TIME、SQL_TIMESTAMP、SQL_VARCHAR

TIMESTAMP

SQL_CHAR、SQL_DATE、SQL_TIME、SQL_TIMESTAMP、SQL_VARCHAR

TIMESTAMP2

SQL_CHAR、SQL_DATE、SQL_TIME、SQL_TIMESTAMP、SQL_VARCHAR

VARCHAR

SQL_CHAR、SQL_DATE、SQL_TIME、SQL_TIMESTAMP、SQL_VARCHAR

メモ：CONVERT 関数には DATETIME のミリ秒部分を切り捨てることができるオプションパラメーターがあります。変換関数の Convert 関数を参照してください。

表 116

DATE、DATETIME、TIME、TIMESTAMP、TIMESTAMP2、VARCHAR

DATE

DATE、DATETIME、TIMESTAMP、VARCHAR

DATETIME

任意のリレーショナルデータ型

TIME

TIME、DATETIME、TIMESTAMP、TIMESTAMP2、VARCHAR

TIMESTAMP

DATE、DATETIME、TIME、TIMESTAMP、TIMESTAMP2、VARCHAR

TIMESTAMP2

DATE、DATETIME、TIME、TIMESTAMP、TIMESTAMP2、VARCHAR

VARCHAR

DATE、DATETIME、TIME、TIMESTAMP、TIMESTAMP2

UNIQUEIDENTIFIER

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

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

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

•

NEWID() スカラー関数を使用します。NEWID( ) を参照してください。

•

'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' 形式の引用符で囲んだ文字列を指定します。x は 0-9 または A-F の範囲の 16 進数です。たとえば、'1129619D-772C-AAAB-B221-00FF00FF0099' は有効な UNIQUEIDENTIFIER 値です。

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

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

演算子	意味
=	等しい
<> または !=	等しくない
<	より小さい
>	より大きい
<=	小さいかまたは等しい
>=	大きいかまたは等しい
IS NULL	値はヌルです
IS NOT NULL	値はヌルではありません

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

変数を宣言する

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

DECLARE :Cust_ID UNIQUEIDENTIFIER DEFAULT NEWID()

DECLARE :ISO_ID uniqueidentifier

SET :ISO_ID = '1129619D-772C-AAAB-B221-00FF00FF0099'

UNIQUEIDENTIFIER を別のデータ型に変換する

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

•

CHAR

•

LONGVARCHAR

•

VARCHAR

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

無限の表現

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

表 117

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

表 118

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

Btrieve キーのデータ型

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

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

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

表 119

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 中にこの値を小さくすることができます。

•

キー内にある最大の autoincrement 値が、ファイルに対する次の autoincrement 値よりも小さい。

•

ほかのどのクライアントも、最大の autoincrement 値を含んでいるページに影響を与えるトランザクションを保留にしていない。

•

最大の autoincrement 値を含むキーページが、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 型のキーには次の制限が適用されます。

•

重複のないキーとして定義する必要があります。

•

キーをセグメントキーにすることはできません。ただし、autoincrement キーが個別の単一のキーとして最初に定義されており、autoincrement キー番号がセグメントキーのキー番号よりも小さい場合に限り、autoincrement キーを別のキーの整数セグメントとして含めることができます。

•

ほかのキーとオーバーラップすることはできません。

•

キーはすべて昇順でなければなりません。

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

•

autoincrement キーにバイナリ 0 の値を指定した場合、MicroKernel は以下の基準に沿ってキーに値を割り当てます。

•

ファイルに最初のレコードを挿入する場合、MicroKernel は autoincrement キーに値 1 を割り当てます。

•

ファイル内に既にレコードが存在する場合、MicroKernel は autoincrement キーに、ファイル内の既存の最も大きい絶対値より 1 大きい値を割り当てます。

•

autoincrement キーに 0 以外の正の値を指定した場合、MicroKernel はファイルにレコードを挿入し、指定した値をキー値として使用します。その値を含むレコードがファイルに既に存在する場合、MicroKernel はエラーステータスコードを返し、そのレコードを挿入しません。

AUTOTIMESTAMP

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 で失敗します。

AUTOTIMESTAMP を使用した挿入と更新

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 型のキーを作成する場合には、次の制限が適用されます。

•

NOCASE フラグをキーに適用することはできません。

•

NULL_KEY および MANUAL_KEY は指定できません。タイムスタンプをインデックスから除外することはできません。

Function Executor および Maintenance ツールでの使い方

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

BFLOAT

BFLOAT キータイプは、単精度実数または倍精度実数です。単精度実数は、23 ビットの仮数、128 でバイアスされた 8 ビットの指数、および符号ビットで格納されます。4 バイト float の内部レイアウトは次のとおりです。

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

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

STRING

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

CURRENCY

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

DATE

DATE キータイプは、内部的に 4 バイト値として格納されます。日と月はそれぞれ 1 バイトのバイナリ形式で格納されます。年は、年の値全体を表す 2 バイトのバイナリ数です。MicroKernel は、日を 1 番目のバイトに、月を 2 番目のバイトに、年を月に続く 2 バイトの WORD に置きます。

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

TYPE dateField {
char day;
char month;
integer year;
}

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

DECIMAL

DECIMAL キータイプは、内部的に、1 バイトごとに 2 つの 10 進数を含む、パックされた 10 進数として格納されます。n バイトの DECIMAL フィールドの内部表現法は次のとおりです。

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 を必ず使用することに留意してください。

Windows

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

HKEY_LOCAL_MACHINE\SOFTWARE\Actian\Zen\SQL Relational Engine

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

注意：レジストリの編集は高度な操作です。誤って編集すると、オペレーティングシステムが起動しなくなる恐れがあります。必要であれば、経験豊富な技術者に依頼して編集を行ってもらってください。Actian Corporation はレジストリの破損に対して責任を負いません。

Linux および macOS

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

./psregedit -set -key PS_HKEY_CONFIG/SOFTWARE/Actian/Zen/"SQL Relational Engine" -value "CommonCOBOLDecimalSign" -type PS_REG_STR "YES"

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

./psregedit -set -key PS_HKEY_CONFIG_64/SOFTWARE/Actian/Zen/"SQL Relational Engine" -value "CommonCOBOLDecimalSign" -type PS_REG_STR "YES"

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

FLOAT

注意： C 言語の定義が FLOAT（4 バイト）または DOUBLE（8 バイト）データ型に対してサポートしている精度を超える精度は失われます。小数点以下の桁数が多い数値に精度が要求される場合は、DECIMAL 型の使用を考慮してください。

FLOAT キータイプは、単精度実数または倍精度実数の IEEE 規格に準拠しています。4 バイト FLOAT の内部形式は次のように、23 ビットの仮数、127 でバイアスされた 8 ビットの指数、および符号ビットで構成されます。

8 バイトの FLOAT キーは、52 ビットの仮数、1023 でバイアスされた 11 ビットの指数、および符号ビットを持ちます。内部形式は次のとおりです。

GUID

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

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

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

GUID キー

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

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

INTEGER

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

表 120

-2147483648 – 2147483647

-9223372036854775808 – 9223372036854775807

LOGICAL

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

LSTRING

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

MONEY

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

NUMERIC

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

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

表 121

NUMERICS の符合値のシフト状態とシフトなし状態の比較

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

Windows 32 ビット

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

HKEY_LOCAL_MACHINE\SOFTWARE\Actian\Zen\Database Names

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

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

注意： Windows レジストリを誤って編集すると、Windows を起動できなくなる可能性があります。編集は、訓練を受けた IT 担当者のみが行ってください。Actian Corporation は Windows レジストリの破損に対して責任を負いません。

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

Linux および macOS

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

[Database Names]
DBCobolNumeric=yes

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

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

正の NUMERIC データの符合値の整合

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

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

NUMERICSA

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

表 122

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

表 123

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

NUMERICSTB

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

表 124

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

TIME

TIME キータイプは、内部的に 4 バイト値として格納されます。100 分の 1 秒、秒、分、時の値が、それぞれ 1 バイトのバイナリ形式で格納されます。MicroKernel は、100 分の 1 秒の値を最初のバイトに、それ以降のバイトにそれぞれ秒、分、時の値を置きます。データ形式は hh:mm:ss.nn です。サポートされる値の範囲は 00:00:00.00 ～ 23:59:59.99 です。

TIMESTAMP

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 は、新しいレコードが挿入されたとき、または既存のレコードが初めて更新されたときの現在の時刻に自動的に置き換えられません。

メモ：ODBC 標準に従って、CURRENT_TIMESTAMP() や NOW() などのスカラー関数は、データ型のうち小数の秒を表す部分は無視します。これらの関数を使用する際、Zen は小数の秒を無視しないで、3 桁のミリ秒を表示するという点に注意することが重要です。

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

YEAR	0001 ～ 9999
MONTH	01 ～ 12
DAY	01 ～ 31、グレゴリオ暦の年と月の値によって決められます。
HOUR	00 ～ 23
MINUTE	00 ～ 59
SECOND	00 ～ 59
MILLISECOND	000 ～ 999。デフォルトの設定。小数位は、0 ～ 7（セプタ秒）の値に設定できます。

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

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

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

注意：データベースエンジンを実行するコンピューターのタイムゾーン情報が正しく設定されていることが重要です。タイムゾーンを移動するか、タイムゾーン情報を変更した場合、返されるデータは UTC から現地時刻に変換されるときに変わります。現地時刻および UTC の変換は、リレーショナルエンジン内で、リレーショナルエンジンが動作している場所のタイムゾーン情報を使用して発生します。リレーショナルエンジンとタイムゾーンが異なるセッションのタイムゾーン情報は、現地時刻および UTC の変換には使用されません。

タイムスタンプデータは格納する前に変換されるため、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 ツールでの使い方

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

TIMESTAMP2

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

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

メモ：ODBC 標準に従って、CURRENT_TIMESTAMP() や NOW() などのスカラー関数は、データ型のうち小数の秒を表す部分は無視します。これらの関数を使用する際、Zen は小数の秒を無視しないで、9 桁のナノ秒を表示するという点に注意することが重要です。

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

YEAR	1970 ～ 2554
MONTH	01 ～ 12
DAY	01 ～ 31、グレゴリオ暦の年と月の値によって決められます。
HOUR	00 ～ 23
MINUTE	00 ～ 59
SECOND	00 ～ 59
NANOSECOND	000000000 ～ 999999999デフォルトの設定。