SQL92が提示している広範囲にわたるデータタイプ・リストのすべてを、FrontBaseではサポートしている。さらに、FrontBaseはSQL3に由来する、数々のデータタイプをもサポートしている。データタイプのリストは、長く、ややもすれば混同しやすいものかもしれないが、心配することはない。名前の多くは、同じデータタイプを意味しているからである（コミッティに由来した作業結果である）。
| SQL92 データタイプ： |
SMALLINT |
INTEGER |
INT |
| DECIMAL |
NUMERIC |
FLOAT |
| REAL |
DOUBLE PRECISION |
|
| CHARACTER |
CHAR |
|
| NATIONAL CHARACTER |
NATIONAL CHAR |
NCHAR |
| CHARACTER VARYING |
CHAR VARYING |
VARCHAR |
| NATIONAL CHARACTER VARYING |
NATIONAL CHAR VARYING |
NCHAR VARYING |
| BIT |
BIT VARYING |
|
| DATE |
TIME |
INTERVAL |
| TIME WITH TIME ZONE |
TIMESTAMP |
TIMESTAMP WITH TIME ZONE |
|
| SQL3 に由来するデータタイプ |
BLOB |
CLOB |
BOOLEAN |
|
| FrontBase 独自のデータタイプ |
BYTE |
|
|
SMALLINT
16ビット整数値としてインプリメントされる。
例：
CREATE TABLE T0(C0 SMALLINT, ...);
INTEGER, INT
32ビット整数値としてインプリメントされる。わかりきった用途は別として、このデータタイプは、時に、単一列のPRIMARY KEYとして使われることもある。もし、EOFを使っている場合は、EOFの自動生成プライマリ・キーを使って調べてみたいと思うかもしれないし、EOFとしてのBYTEタイプは、データベースへのアクセスなしに、キーを生成することができる。トレードオフは、32ビット整数値のプライマリ・キーが大変シンプルであるのに対し、12バイトのプライマリ・キーというのが、理解しにくいものであるという点であろう。
例：
CREATE TABLE T0(C0 INTEGER PRIMARY KEY, ...);
DECIMAL[ ( <precision> [ , <scale> ] ) ]
128ビットの整数値と、32ビットの符号を含む指数部としてインプリメントされる。<precision>に対するデフォルトの値は38（すなわち最大値）で、<scale>のデフォルト値は、0である。この表記法は、NSDecimalNumberに独特なものである。指示部を固定したいなら、このデータタイプが適しているだろう。DECIMALの一般的な使い方としては、通貨に関係する値を扱う場合が挙げられる。
FrontBaseでは、基底部に10桁を使うが、これで正確さが損なわれることはない。たとえば、1.23をINSERTした場合、この値は、そのまま取得されストアされたり、返される。1.229994599といった形に変換されることはない。同様のことは、NUMERIC、FLOAT、DOUBLE PRECISION（次節参照）といったデータタイプにもあてはまる。
例：
CREATE TABLE T0(C0 DECIMAL, PROFITS DECIMAL(20,2), ...);
NUMERIC[ ( <precision> [ , <scale> ] ) ]
64ビット整数値＋32ビットの符号を含む指数部としてインプリメントされる。<precision>に対するデフォルトの値は19（すなわち最大値）で、<scale>のデフォルト値は、0である。38桁の正確さを求めるのでなければ、NUMERICをDECIMALの代わりとして用いることができる（これにより、必要となるディスクスペースを減らすことも可能である）。
例：
CREATE TABLE T0(C0 NUMERIC, SALARY NUMERIC(10,2), ...);
FLOAT[ ( <precision> ) ]
64ビット整数値＋32ビットの符号を含む指数部としてインプリメントされる。<precision>のデフォルト値は19（すなわち最大値）である。
例：
CREATE TABLE T0(C0 FLOAT, C1 FLOAT(10), ...);
REAL
64ビットの整数値＋32ビットの符号を含む指数部としてインプリメントされる。<precision>のデフォルト値は19（すなわち最大値）である。REALおよびFLOATは、区別をつけてインプリメントされるが、FLOATを使うときは、例外的に、このREALを、<precision>を最大値にして、指定・使用することも可能である。
例：
CREATE TABLE T0(C0 REAL, ...);
DOUBLE PRECISION
128ビットの整数値＋32ビットの符号をh組む指数部としてインプリメントされる。<precision>のデフォルト値は38（すなわち最大値）である。様々な目的に応じて、このデータタイプをNSDecimalNumber/java.math.BigDecimalにマップするのは、最適の選択だろう。詳細については“Mapping of Foundation/Java objects into FrontBase”を参照のこと。
例：
CREATE TABLE T0(C0 DOUBLE PRECISION, ...);
CHARACTER, CHAR
昔ながらの、固定長キャラクタ・ストリングとしてインプリメントされる。FrontBaseでは、Unicodeを包括的に扱い、全キャラクタ・ストリングをUTF8エンコーディングとしてストアすることに注意すること。これは、ASCIIよりも、値をもったキャラクタ・ストリングが、同じ文字数でも、より多くのバイト数を占めるということを意味している。非ASCIIキャラクタ、たとえば、 æøåÆØÅといったものは、UTF8フォーマットにエンコードされるとき、2バイトを占有する。
CHARACTER値の最大長は、2GBである。
例：
CREATE TABLE T0(C0 CHAR(1), C1 CHARACTER(100000), ...);
NATIONAL CHARACTER, NATIONAL CHAR, NCHAR
FrontBaseUnicodeを包括的に扱っているため、NATIONAL CHARACTERデータタイプは、CHARACTERの中に割り当てられる。
例：
CREATE TABLE T0(C0 NATIONAL CHAR(1), C1 NCHAR(100000), ...);
CHARACTER VARYING, CHAR VARYING, VARCHAR
昔ながらの固定長キャラクタ・ストリングとしてインプリメントされる。可変長ストリングのインプリメンテーションは非常に効果的で、特に大変長いストリングを扱うときも余分な経費がかからない。長さ16バイトまでのストリングは、直接、行レコードにストアされる（固定長ストリングの場合である）。いわゆる、スペル・テーブルは、各テーブルと関連付けられ、テーブル行に挿入される、個々の可変長ストリングはすべて、一度だけストアされる。
FrontBaseは、VARCHARを大変効果的にエンコードするため、固定長ストリングを用いるよりも、可変長ストリングを用いることを一般的には推奨している。
例：
CREATE TABLE T0(C0 VARCHAR(128), C1 CHARACTER VARYING(200000), ...);
NATIONAL CHARACTER VARYING, NATIONAL CHAR VARYING, NCHAR VARYING
FrontBaseは、Unicodeを包括的にサポートしているので、NATIONAL CHARACTER VARYINGデータタイプは、すべてCHARACTER VARYIGに割り当てられる。
例：
CREATE TABLE T0(C0 NATIONAL CHAR VARYING(10),
C1 NCHAR VARYING(10000), ...);
BIT
BITデータタイプは、概念として、1と0からなるストリングである。しかし、これはバイナリ・データタイプとしては、ややあいまいにインプリメントされる。たとえば、BIT(8)は、1バイトを占める。関係する項目として、以下の、EOFやBYTEの項目も参照すること。
例：
CREATE TABLE T0(C0 BIT(32), C1 BIT(256)...);
BIT VARYING
BITと基本的に同じであるが、明らかな違いとしては、BITストリングは可変長であるという点が挙げられる。
As BIT, but with the obvious exception that the bit strings are variable in length.
例：
CREATE TABLE T0(C0 BIT VARYING(32), C1 BIT VARYING(256)...);
BYTE
BITの上位概念。つまり、BYTE(n)は、BIT(n*8)に等しい。このデータタイプは、SQL92標準ではないが、EOFの自動プライマリ・キー生成をサポートしているという点で便利である。12バイトのバイナリ・キーを使う場合、EOFは、データベース・サーバとクライアント間を往復することなしに、自動的にプライマリ・キーを生成する（これにより、初期化されるトランザクションが始まる）。
例：
CREATE TABLE T0(C0 BYTE(12), ...);
DATE
昔ながらのデータタイプ。DATEは、時刻に関するコンポーネントをまったく含んでいないことに注意すること。DATEの値は、内部的には、（2001-01-01をゼロとして）秒数で表現されており、NUMERIC(0)の値としてストアされている。
例：
CREATE TABLE T0(C0 DATE, ...);
TIME
タイムスタンプのうち、時刻に関するコンポーネントのみからなる。（'12:34:23'のような）TIMEの値は、内部的には、秒数で表現され、UMERIC値としてストアされている。TIMEの値は、負になることもありえることに注意すること。これは、サーバが属するタイムゾーンに関係する。TIMEが挿入されるとき、サーバのタイムゾーンが、timeの値に適用されるからである。
例：
CREATE TABLE T0(C0 TIME, ...);
TIME WITH TIME ZONE
TIMEと基本的にあ同じであるが、タイムゾーンのオフセットが含めて、timeの値（'12:34:23-08:00'）をストアする。このデータタイプにより、クライアント側に、正確なタイムゾーンを返すことができる。
例：
CREATE TABLE T0(C0 TIME WITH TIME ZONE, ...);
TIMESTAMP
日付および時刻といったコンポーネントをすべて含んだ、完全な形のタイムスタンプ情報を保持する。TIMESTAMPの値は、'2001-01-24 12:34:23'のような形式を取り、内部的には、2001-01-01をゼロとして、秒数で表現されるので、NUMERIC値としてストアされる。TIMESTAMPの値は、サーバのタイムゾーンで表現されるものであることに注意すること。すなわち、時刻の値が挿入されるとき、サーバ側タイムゾーンが適用されるのである。これは、TIMESTAMPの値が、クライアント側のタイムゾーンとは異なる可能性があるということだ！
例：
CREATE TABLE T0(C0 TIMESTAMP, ...);
TIMESTAMP WITH TIME ZONE
TIMESTAMPとの違いは、タイムゾーンのオフセットを含めて、時刻の値をストアする点である。形式としては、'2001-01-24 12:34:23-08:00'のようになる。クライアント側に、性格なタイムゾーンが返される。このデータタイプは、どんなタイムゾーン情報がストアされ、表示されるかを完全に制御したい場合に、必要となるだろう。
例：
CREATE TABLE T0(C0 TIMESTAMP WITH TIME ZONE, ...);
INTERVAL
INTERVALは、実際には2つのデータタイプに分けられる：1つ目は、いわゆる年−月の間隔で、もう1つは、日付−時刻の間隔である。
年−月の間隔は、内部的には、月数で表現され、32ビットの整数値としてストアされる。
日付−時刻の間隔は、内部的には秒数で表現され、NUMERIC値としてストアされる。
INTERVALの使い道としては、日付とタイムスタンプを操作するときが考えられる。すなわち、日にちあるいは月数を加えるのである：:
DATE '2000-01-25' + INTERVAL '02' MONTH (結果： DATE '2000-03-25' )
or
DATE '2000-02-28' + INTERVAL '02' DAY (結果： DATE '2000-03-01' )
例：
CREATE TABLE T0(C0 INTERVAL YEAR TO MONTH, C1 INTERVAL MONTH, ...);
CREATE TABLE T1(D0 INTERVAL DAY TO SECOND, C1 INTERVAL HOUR, ...);
BLOB
Binary Large OBjectは、ややあいまいな、バイナリのデータタイプである。ストアしたバイト数は、どんな形に解釈されることはなく、挿入されたときとまったく同じ形で返される。FrontBaseは、サーバがわでストリーミングするなど、BLOBを大変効果的にインプリメントするため、コピーする必要性はまったくない。クライアント側の巣とリーミングは、FrontBase2.0から可能になるよう、計画されている。BLOBの値は、最大で2GBまで取ることができる。
例：
CREATE TABLE T0(C0 BLOB, ...);
CLOB
Character Large OBjectは、巨大なキャラクタ・ストリング向けのデータタイプである。たとえば、検索したくないようなキャラクタ・ストリングや、通常のCHARACTER/VARCHAR値に対し、効果的に値を増やしていくような場合である（CHARACER/VARCHARの値は、INSERTあるいはUPDATE SQLステートメントに コピーされる）。CLOBは、BLOB同様、非常に効果的にインプリメントされている。CLOBの値は、UTF8フォーマットでエンコードされ、デコードは、クライアント側で実行される。
例：
CREATE TABLE T0(C0 CLOB, ...);
BOOLEAN
符号なしの1バイトでインプリメントされる。SQL92では、3つの論理的値を使うことに注意すること。すなわち、このデータタイプの値としては、FALSE(0)、TRUE(1)、そしてUNKOWN(255)が可能である。
例：
CREATE TABLE T0(C0 BOOLEAN, ...);
|
