CREATE TABLE
CREATE TABLE ステートメントにより、データベース内に新しいテーブルを作成します。
CREATE TABLE には、最小またはコア SQL 準拠よりも高度な機能が含まれています。CREATE TABLE では参照整合性機能がサポートされます。Pervasive PSQL は、ColIDList サポートを除いて、SQL 92 にほぼ準拠しています。
CREATE TABLE ステートメントを使用してテンポラリ テーブルを作成することもできます。
CREATE （テンポラリ） TABLE を参照してください。
注意： 同じディレクトリに、ファイル名が同一で拡張子のみが異なるようなファイルを置かないでください。たとえば、同じディレクトリ内に Invoice.btr と Invoice.mkd というテーブル（データ ファイル）を作成しないでください。このような制限が設けられているのは、データベース エンジンがさまざまな機能でファイル名のみを使用し、ファイルの拡張子を無視するためです。ファイルの識別にはファイル名のみが使用されるため、ファイルの拡張子だけが異なるファイルは、データベース エンジンでは同一のものであると認識されます。
構文
(テーブル要素[, テーブル要素]...)
個数 ::= ユーザー定義値（リンク重複インデックス キーを追加するために予約しておくポインタの数を設定します）
テーブル要素 ::= 列定義 | テーブル制約定義
列定義 ::=
列名 データ型 [
DEFAULT デフォルト値の式] [
列制約定義 [
列制約定義]...[
CASE（文字列） |
COLLATE コレーション名]
データ型 ::=
データ型名 [(
桁数[,
小数位])]
桁数 ::= 整数
小数位 ::= 整数
デフォルト値の式 ::= デフォルト値の式 + デフォルト値の式
| デフォルト値の式 - デフォルト値の式
| デフォルト値の式 * デフォルト値の式
| デフォルト値の式 / デフォルト値の式
| デフォルト値の式 & デフォルト値の式
| デフォルト値の式 | デフォルト値の式
| デフォルト値の式 ^ デフォルト値の式
| ( デフォルト値の式)
| -デフォルト値の式
| +デフォルト値の式
| ~デフォルト値の式
| ?
| リテラル
| スカラー関数
| {fn スカラー関数｝
| NULL
リテラル ::= '文字列'
| 数字
| {d '日付リテラル'}
| {t '時刻リテラル'}
| {ts 'タイムスタンプ リテラル'}
列制約定義 ::= [CONSTRAINT 制約名] 列制約
制約名 ::= ユーザー定義名
列制約 ::= NOT NULL
| NOT MODIFIABLE
| REFERENCES テーブル名 [(列名)] [参照アクション]
テーブル制約定義 ::= [CONSTRAINT 制約名] テーブル制約
テーブル制約 ::=
UNIQUE (
列名[,
列名]...)
REFERENCES テーブル名 [(列名[, 列名]...)] [参照アクション]
参照アクション ::= 参照更新アクション [参照削除アクション]
| 参照削除アクション [参照更新アクション]
コレーション名 ::= '文字列' | ユーザー定義名
備考
CREATE TABLE ステートメントで作成されるインデックスは、IDENTITY、主キー、および外部キーのみです。その他のインデックスは
CREATE INDEX ステートメントで作成する必要があります。
外部キー制約名は、辞書内で固有の名前でなければなりません。その他の制約名はすべて、常駐するテーブル内で固有の名前であり、列とは異なる名前でなければなりません。
主キー名が省略された場合は、キー内の最初の列名に接頭辞 "PK_" を付けた名前が制約名として使用されます。
参照列が一覧にない場合は、デフォルトでは参照されるテーブルの主キーが参照の対象になります。主キーが使用できない場合は、"キーがありません" というエラーが返されます。ターゲット列を列挙すると、このような状況を回避できます。
外部キー名が省略された場合は、キー内の最初の列名に接頭辞 "FK_" を付けた名前が制約名として使用されます。
UNIQUE 制約が省略された場合は、キー内の最初の列名に接頭辞 "UK_" を付けた名前が制約名として使用されます。
NOT MODIFIABLE 制約が省略された場合は、キー内の最初の列名に接頭辞 "NM_" を付けた名前が制約名として使用されます。（NOT MODIFIABLE が使用されている場合は、列に一意でない変更不可能なインデックスが作成されます。このインデックスは、NM_列名となります。）
NOT NULL 制約が省略された場合は、キー内の最初の列名に接頭辞 "NN_" を付けた名前が制約名として使用されます。
外部キーが同じテーブルの主キーを参照する場合があります（自己参照キーと呼ばれる）。
CREATE TABLE が成功して USING 句が指定されていない場合、作成されたテーブルのデータ ファイル名は xxx.mkd になります。xxx は指定したテーブル名です。物理ファイルの xxx.mkd が既に存在する場合は xxxnnn.mkd という名前の新しいファイルが作成されます。nnn は一意の番号です。テーブルが既に存在する場合、そのテーブルは置換されず、エラー - 1303 "テーブルは既に存在します" が返されます。テーブルを置換する前に削除する必要があります。
レコード サイズの制限
データ レコードの固定長部分の合計サイズは、65535 バイトを超えてはいけません。データ レコードの固定長部分は次の要素で構成されます。
•固定サイズのすべての列（LONGVARCHAR 型および LONGVARBINARY 型以外のすべての列）
•ヌル値を許可する各列について 1 バイト
•各可変長列（LONGVARCHAR 型または LONGVARBINARY 型の列）について 8 バイト
この制限を超えるテーブルの作成を試みるか、結果としてテーブルが制限を超えるような変更を試みると、Pervasive PSQL はステータス コード -3016 "テーブルの最大固定長行サイズを超えています" を返します。
新しいテーブルを作成する前にレコードの固定長部分のバイト単位のサイズを調べるには、次の計算式を使用します。
（固定長列のバイト単位の記憶域サイズ合計）+（ヌル値を許可する列の数）+（8 * 可変長列の数） = バイト単位のレコード サイズ
既存データ ファイルのレコードの固定長部分のサイズを調べたい場合は、BUTIL -STAT コマンドを使用すれば、この情報を示すレポートを表示できます。
例
次のような列が定義されているテーブルがあるとします。
データ型 | このデータ型の列数 | ヌル値を許可 |
VARCHAR(216) | 1 | 可 |
VARCHAR(213) | 5 | すべての列 |
CHAR(42) | 1494 | すべての列 |
VARCHAR にはそれぞれ余分に 2 バイトが予約されます。先頭のヌル インジケーター用の 1 バイトと末尾の 1 バイトです。末尾のバイトは、VARCHAR が ZSTRING として実装されるためです。CHAR にはそれぞれ先頭のバイトがヌル インジケーター用に予約されます。
したがって、レコード サイズは 1 x 218 + 5 x 215 + 1494 x 43 = 65535 バイトになります。
この例では、別の列がどのような長さであっても、固定長制限を超えないで追加することはできません。
削除規則
外部キー制約を持つ ON DELETE キーを含めることで、外部キー値が参照する親テーブルの行を削除しようとする場合に Pervasive PSQL により適用される削除規則を定義することができます。選択可能な削除規則は次のとおりです。
•CASCADE を指定した場合、Pervasive PSQL はカスケード削除規則を使用します。ユーザーが親テーブルの行を削除すると、データベース エンジンによって従属テーブルの対応する行が削除されます。
•RESTRICT を指定した場合、Pervasive PSQL は削除制限規則を使用します。ユーザーは、親テーブル内で、外部キー値が参照する行を削除できません。
削除規則を指定しない場合、Pervasive PSQL はデフォルトで制限規則を適用します。
DELETE CASCADE は注意して使用してください。Pervasive PSQL では、自己参照するテーブルに対し、循環するカスケード削除を使用できます。『
Advanced Operations Guide』の
削除カスケードに記載されている例を参照してください。
更新規則
Pervasive PSQL は更新制限規則を適用します。この規則は、親テーブルが外部キー値と合致する主キー値を持たない場合、その外部キー値を含む行が追加されないようにします。この規則が適用されるかどうかは、更新規則を明示的に指定できるオプションの ON UPDATE 句の使用によります。
IN DICTIONARY
ALTER TABLE の IN DICTIONARY の解説を参照してください。
USING
USING キーワードを使用すると、特定のデータ ファイルを CREATE TABLE または ALTER TABLE アクションと関連付けることができます。
Pervasive PSQL は接続に名前付きデータベースを必要とするので、指定するパス名は常に単純なファイル名であるか、または相対パスとファイル名でなければなりません。パスは常に、接続する名前付きデータベースに指定された最初のデータ パスとの相対になります。
渡されたパス名およびファイル名は、SQLPrepare が呼び出されるときに部分的に検証されます。パス名を指定するときは、次の規則に従う必要があります。
•テキストは、文法定義で示されているように、一重引用符で囲まなければなりません。
•テキストの長さは、使用しているメタデータのバージョンの制限を超えることはできません。エントリは入力したまま正確に Xf$Loc に格納されます（ただし、後続の空白は切り捨てられ、無視されます）。
Xf$Loc（メタデータ バージョン 1用）および
Xf$Loc（メタデータ バージョン 2用）を参照してください。
•パスは、単純な相対パスでなければなりません。サーバーまたはボリュームを参照するパスは許可されません。
•1 つのピリオド（"." は現在のディレクトリ）、2 つのピリオド（".." は親ディレクトリ）、円記号 "\"、あるいはこれら 3 つのあらゆる組み合わせを含む相対パスを使用できます。パスは、SQL テーブル名を表すファイル名を含んでいる必要があります（パス名は円記号 "\" またはディレクトリ名で終わってはいけません）。ファイル名は、相対パス付きで指定されたファイル名も含めてすべて、名前付きデータベースの設定で定義されている最初のデータ パスとの相対になります。
•ルート ベースの相対パスも使用できます。たとえば、最初のデータ パスを D:\mydata\DEMODATA とした場合、Pervasive PSQL は次のステートメント内のパス名を D:\TEMP\TEST123.BTR と解釈します。
CREATE TABLE t1 USING '\temp\test123.btr' (c1 int)
•相対パス内の円記号（"\"）文字は、好みに応じて、LINUX スタイル（"/"）と通常使われる円記号（"\"）のどちらを指定してもかまいません。必要であれば、2 種類の記号を混在させて使用することもできます。ディレクトリ構造スキーマは知っているかもしれませんが、接続されているサーバーの種類を知っている（あるいは管理している）とは限らないので、これは便利な機能です。パスは入力したとおりに X$File に格納されます。Pervasive PSQL エンジンは、パスを利用してファイルを開く際、円記号文字を適切なプラットフォームのタイプに変換します。また、データ ファイルはサポートされるすべてのプラットフォーム間でバイナリ互換性を共有するため、ディレクトリ構造がプラットフォーム間で同一である（および、パスに基づくファイル名が相対パスで指定されている）限りは、データベース ファイルおよび DDF をこれらに変更を加えることなく、あるプラットフォームから別のプラットフォームへ移動することができます。これは、複数のプラットフォームにまたがって、標準化されたデータベース スキーマをより簡単に配置するのに役立ちます。
•相対パスを指定する場合、まず USING 句のディレクトリ構造は存在している必要があります。Pervasive PSQL は、USING 句で指定されたパス条件を満たすディレクトリを作成しません。
USING 句を使用して、テーブルと関連付けるデータ ファイルの物理的な場所を指定します。これは、既存データ ファイルのテーブル定義を作成するとき、または新しいデータ ファイルの名前や物理的な場所を明示的に指定したい場合は必須です。
USING 句を使用しないと、Pervasive PSQL により固有のファイル名（テーブル名を基に拡張子 .MKD を付けて）が生成され、データベース名と関連付けられたデータ ファイル パスに指定されている最初のディレクトリにデータ ファイルが作成されます。
USING 句が既存のデータ ファイルを示す場合は、Pervasive PSQL により DDF にテーブルが作成され、SQL_SUCCESS_WITH_INFO が返されます。返された情報メッセージは、辞書エントリが既存のデータ ファイルをポイントするようになったことを示します。CREATE TABLE で SQL_SUCCESS のみが返されるようにしたい場合は、CREATE ステートメントで IN DICTIONARY を指定します。WITH REPLACE を指定する（下記参照）と、同一名の既存データ ファイルはすべて破棄され、新規に作成したファイルで上書きされます。
メモ： 既存のデータ ファイルを指定した場合、Pervasive PSQL は成功を表すステータス コードを返します。
既存のデータ ファイルに対してリレーショナル インデックス定義を作成する（たとえば、IDENTITY 型の列定義を含む CREATE TABLE USING ステートメントを使用する）たびに、Pervasive PSQL はそのファイルに定義されている Btrieve インデックスを自動的にチェックし、既存の Btrieve インデックスがリレーショナル インデックス定義に必要なパラメーターのセットを提供しているかどうかを判定します。既存の Btrieve インデックスと作成する新しい定義が一致する場合は、リレーショナル インデックス定義と既存の Btrieve インデックスの間に関連付けが作成されます。一致するインデックスがない場合は、Pervasive PSQL は新しいインデックス定義を作成し、IN DICTIONARY が指定されていなければ、データ ファイルに新しいインデックスを作成します。
WITH REPLACE
WITH REPLACE が USING キーワードと共に指定されたときはいつでも、Pervasive PSQL は既存のファイル名を指定されたファイル名で自動的に上書きします。オペレーティング システムがファイルの上書きを許している限り、既存ファイルは常に上書きされます。
WITH REPLACE はデータ ファイルにのみ作用し、DDF には作用しません。
WITH REPLACE を使用する際には次の規則が適用されます。
•WITH REPLACE は USING と併せてのみ使用できます。
•IN DICTIONARY と一緒に使用すると、WITH REPLACE は無視されます。IN DICTIONARY は DDF にのみ作用することを指定するものだからです。
CREATE TABLE ステートメントで WITH REPLACE を使用した場合、USING 句で指定された場所にファイルが存在すると、Pervasive PSQL は新規データ ファイルを作成してその既存ファイルと置き換えます。Pervasive PSQL は、同じ名前を持つ元のファイルに格納されているデータをすべて破棄します。WITH REPLACE を使用していないとき、指定された場所にファイルが存在すると、Pervasive PSQL はステータス コードを返し、新しいファイルを作成しません。ただし、テーブル定義は DDF に追加されます。
WITH REPLACE はデータ ファイルにのみ作用し、辞書内のテーブル定義には作用しません。
DCOMPRESS
DCOMPRESS オプションは、ディスク上のファイル サイズを減らすために、指定したテーブルのデータ ファイルがレコード圧縮を使用することを指定します。
次の例では、レコード圧縮を行う、ページ サイズが 1024 バイトのテーブルが作成されます。
CREATE TABLE t1 DCOMPRESS PAGESIZE=1024 (c1 INT DEFAULT 10, c2 CHAR(10) DEFAULT 'abc')
レコード圧縮の詳細については、『
Advanced Operations Guide』の
レコードおよびページ圧縮を参照してください。
PCOMPRESS
PCOMPRESS オプションは、指定したテーブルのデータ ファイルがページ圧縮を使用することを指定します。次の例では、ページ圧縮を行う、ページ サイズが 1024 バイトのテーブルが作成されます。
CREATE TABLE t1 PCOMPRESS PAGESIZE=1024 (c1 INT DEFAULT 10, c2 CHAR(10) DEFAULT 'abc')
ページ圧縮の詳細については、『
Advanced Operations Guide』の
レコードおよびページ圧縮を参照してください。
PAGESIZE
PAGESIZE オプションは、指定したテーブルのデータ ファイルが使用するページのサイズ バイト数を指定します。サイズの値には、ファイル バージョンに応じて次のような値を指定できます。
•512 － 4096：9.0 より前のファイル バージョンの場合（512 バイトの倍数で最大 4096 バイト）
•512、1024、1536、2048、2560、3072、3584、4096 または 8192：ファイル バージョンが 9.0 の場合
•1024、2048、4096、8192 または 16384：ファイル バージョンが 9.5 以上の場合
次の例では、ファイル圧縮を行う、ページ サイズが 8192 バイトのテーブルが作成されると共に、相対パスによって識別される特定のデータ ファイル、..\data1.mkd の作成が指定されます。
CREATE TABLE t1 DCOMPRESS PAGESIZE=8192
USING '..\data1.mkd' (c1 INT DEFAULT 10, c2 CHAR(10) DEFAULT 'abc')
LINKDUP
複数のレコードが、インデックス キーに同一の重複した値を持つことができます。重複キー値を持つレコードを記憶しておく 2 つの方法は、リンク重複（linkdup）および繰り返し重複と呼ばれますリンク重複と繰り返し重複の詳細については、『
Advanced Operations Guide』の
重複キーの操作方法を参照してください。
LINKDUP キーワードが
指定されていない場合、
CREATE INDEX ステートメントは繰り返し重複を使用します。
物理レコード内で、リンク重複インデックスごとに 8 バイトが余分に必要になります。LINKDUP キーワードを使用すると、これ以降に作成するリンク重複インデックス用にこれらの余分なバイトを予約することができます。
したがって、LINKDUP キーワードが指定されている場合は、以下が適用されます。
•ポインター数に指定した値に達しているとき、リンク重複インデックスを削除すると、
CREATE INDEX ステートメントは次のキーに対してリンク重複方法を使用します。
•CREATE INDEX ステートメントは、リンク重複キー用のポインターが予約されていない場合には繰り返し重複キーを作成できません。
例
次の例では、指定されたデータ型を使用して、Student_ID、Transaction_Number、Log、Amount_Owed、Amount_Paid、Registrar_ID、および Comments の列から成る Billing という名前のテーブルがデータベースに作成されます。
CREATE TABLE Billing
(Student_ID UBIGINT,
Transaction_Number USMALLINT,
Log TIMESTAMP,
Amount_Owed DECIMAL(6,2),
Amount_Paid DECIMAL(6,2),
Registrar_ID DECIMAL(10,0),
Comments LONGVARCHAR)
============
次の例では、ID、Dept_Name、Designation、Salary、Building_Name、Room_Number、および Rsch_Grant_Amount の列から成り、列 ID に基づく主キーを持つ Faculty という名前のテーブルがデータベースに作成されます。
CREATE TABLE Faculty
(ID UBIGINT,
Dept_Name CHAR(20) CASE,
Designation CHAR(10) CASE,
Salary CURRENCY,
Building_Name CHAR(25) CASE,
Room_Number UINTEGER,
Rsch_Grant_Amount DOUBLE,
PRIMARY KEY(ID))
次の例では、Name 列にインデックスを作成し、変更不可を指定します。Name 列のデータは変更できません。
CREATE TABLE organizations
(Name LONGVARCHAR NOT MODIFIABLE,
Advisor CHAR(30),
Number_of_people INTEGER,
Date_started DATE,
Time_started TIME,
Date_modified TIMESTAMP,
Total_funds DOUBLE,
Budget DECIMAL(2,2),
Avg_funds REAL,
President VARCHAR(20) CASE,
Number_of_executives SMALLINT,
Number_of_meetings TINYINT,
Office UTINYINT,
Active BIT,)
============
次の例では、生徒の住所を保存するために StudentAddress というテーブルが必要であるとします。Student テーブルの id 列を主キーに変更してから、Student を主テーブルとして参照する StudentAddress テーブルを作成する必要があります（Student テーブルは DEMODATA サンプル データベースの一部です）。StudentAddress テーブルの作成方法を 4 種類示します。
まず、Student テーブルの id 列を主キーにします。
ALTER TABLE Student ADD PRIMARY KEY (id)
次のステートメントは、DELETE CASCADE 規則を使って、Student テーブルの id 列を参照する外部キーを持つ StudentAddress テーブルを作成します。これは、Student テーブル（この場合、Student は親テーブルになる）から行が削除されるときはいつも、StudentAddress テーブル内でその行と同じ id を持つすべての行も削除されることを示します。
CREATE TABLE StudentAddress (id UBIGINT REFERENCES Student (id) ON DELETE CASCADE, addr CHAR(128))
次のステートメントは、DELETE RESTRICT 規則を使って、Student テーブルの id 列を参照する外部キーを持つ StudentAddress テーブルを作成します。これは、Student テーブルから行が削除されたとき、その行と同じ id を持つ行が StudentAddress テーブルに存在する場合は常に、エラーが発生することを示します。親テーブルである Student テーブルの行を削除するには、事前に StudentAddress テーブルでその id を持つ行をすべて明示的に削除する必要があります。
CREATE TABLE StudentAddress (id UBIGINT REFERENCES Student (id) ON DELETE RESTRICT, addr CHAR(128))
次のステートメントは、UPDATE RESTRICT 規則を使って、Student テーブルの id 列を参照する外部キーを持つ StudentAddress テーブルを作成します。これは、Student テーブルに存在しない id を持つ行が StudentAddress テーブルに追加された場合は、エラーが発生することを示します。言い換えると、外部キーに親の行を参照させるには、その前に親の行がなければならないということです。これは Pervasive PSQL のデフォルトの動作です。
なお、Pervasive PSQL ではこれ以外の更新規則を一切サポートしていません。したがって、この規則は明示的に示しても示さなくてもかまいません。また、削除規則を明示的に指定していないので、DELETE RESTRICT 規則が使用されます。
CREATE TABLE StudentAddress (id UBIGINT REFERENCES Student (id) ON UPDATE RESTRICT, addr CHAR(128))
============
次の例は、テーブルの作成時にオルタネート コレーティング シーケンス（ACS）を使用する方法を示します。使用する ACS ファイルは、Pervasive PSQL で提供されるサンプル ファイルです。
CREATE TABLE t5 (c1 CHAR(20) COLLATE 'file_path\upper.alt')
upper.alt は、ソートする際に大文字と小文字を同等に扱います。たとえば、データベースに値 "abc"、"ABC"、"DEF"、"Def" がこの順序で挿入されている場合、upper.alt を使用してソートした結果は "abc"、"ABC"、"DEF"、"Def" となります。
abc と ABC という値、DEF と Def という値は、まったく同一と見なされ、挿入された順序で返されます。標準の ASCII ソートでは、大文字は小文字の前に配列されており、ソート結果は "ABC"、"DEF"、"Def"、"abc" となります。また、SELECT c1 FROM t5 WHERE c1 = "Abc" は、"abc" および "ABC" を返します。
============
次の例は、テーブル t1 を作成し、リンク重複キー用に予約するポインターの数を 4 に設定します。CREATE INDEX ステートメントによって、テーブルにインデックス キーを作成します。
DROP table t1
CREATE TABLE t1 LINKDUP=4 (c1 int, c2 int, c3 int)
CREATE INDEX link_1 on t1(c1,c2)
CREATE INDEX link_2 on t1(c1,c3)
CREATE UNIQUE INDEX link_3 on t1(c3)
CREATE INDEX link_4 on t1(c1)
CREATE INDEX link_5 on t1(c2)
CREATE INDEX link_6 on t1(c2,c3)
CREATE INDEX ステートメントの結果は次のようになります。
•リンク重複キー：link_1、link_2、link_4、link_5
•繰り返し重複キー：link_6（リンク重複キーに使用されるポインターの数が指定値の 4 に達したためです）
DROP INDEX link_2
CREATE INDEX link_7 on t1(c3,c1)
これら 2 つのステートメントを実行すると、次のようになります。
•リンク重複キー：link_1、link_4、link_5、link_7（DROP INDEX ステートメントによって、リンク重複キーに使用されるポインターの数が 3 に減ったので、link_7 をリンク重複キーにすることができます
•繰り返し重複キー：link_6
============
次のステートメントでは、テーブルを作成してヌル値を許可しないことを指定します（つまり、ヌル インジケーター バイトは追加されません）。
CREATE TABLE NoNulls
(ID UBIGINT NOT NULL,
Name CHAR(20) NOT NULL CASE,
Amount DOUBLE NOT NULL)
============
すべての列を NOT NULL として作成する必要がある場合は、まず SET TRUENULLCREATE ステートメントを使用して真のヌルの作成を無効にしてからテーブルを作成することができます。これにより、各列で NOT NULL 属性を指定することを避けられます（
SET TRUEBITCREATE を参照してください）。次のステートメントでは、前の例と同じテーブルを作成します。
SET TRUENULLCREATE=OFF
CREATE TABLE NoNulls2
(ID BIGINT,
Name CHAR(20) CASE,
Amount DOUBLE)
SET TRUENULLCREATE=ON
============
CREATE TABLE では、列に DEFAULT 値を指定することができます。これは、その列に明示的に値を指定しないで行を挿入した場合に使用されます。次のステートメントは、列のデータ型に一致するデフォルト値を持つテーブルを作成します。注意：IDENTITY 列は暗黙的にデフォルト値ゼロを持ち、次に最も大きい値が自動生成されます。
CREATE TABLE Defaults
(ID IDENTITY,
Name CHAR(20) DEFAULT 'none',
Amount DOUBLE DEFAULT 0.00,
EntryDay DATE DEFAULT CURDATE(),
EntryTime TIME DEFAULT CURTIME())
次のステートメントは、デフォルトを使用して 2 行を挿入します。
INSERT INTO Defaults (ID) VALUES (0)
INSERT INTO Defaults (ID, Name, Amount) VALUES (0, 'Joquin', '100')
SELECT ステートメントはデフォルト値を持つ結果を返します。
SELECT * FROM Defaults
ID Name Amount EntryDay EntryTime
=== ======== ======== ========= ===========
1 none 0.0 curdate curtime
2 Joquin 100.0 curdate curtime
============
次の例では、データ ファイル "olddata.dat" に旧形式のデータ型の列を含む Legacydata というテーブルがあると仮定します。新しいデータベースでは旧形式のデータ型を持つテーブルを作成することはできません。ただし、IN DICTIONARY 句を使用して新しいデータベースに旧形式データの DDF 定義を作成することができます。
CREATE TABLE "Legacydata" IN DICTIONARY USING 'olddata.dat' (
"col1" LSTRING(10) NOT NULL,
"col2" VARCHAR(9) NOT NULL,
"col3" LOGICAL NOT NULL,
"col4" LOGICAL2 NOT NULL,
"col5" NOTE(100) NOT NULL);
関連項目