よくある質問

以下は、 ２０１６年１２月現在の sqlite 文書、Frequently Asked Questions 、よくある質問、の、kanda.motohiro@gmail.com による訳です。以下の条件で、公開します。

The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law.

（１）AUTOINCREMENT フィールドを作るにはどうしますか。

短い答え：INTEGER PRIMARY KEY で宣言されたカラムは、自動で加算されます。

長い答え：もしあなたが、テーブルのカラムを INTEGER PRIMARY KEY で宣言したら、そのテーブルのそのカラムに NULL を入れるときにはいつでも、NULLが自動的に整数に変換されます。その値は、そのテーブルのすべての他の行のそのカラムの値の最大値よりも一つ大きいです。もしくは、そのテーブルが空なら、１です。あるいは、可能な最大の整数キーである 9223372036854775807 が使用中である場合は、使われていないキー値がランダムに選ばれます。例えば、このようなテーブルがあるとします。

CREATE TABLE t1(   a INTEGER PRIMARY KEY,   b INTEGER ); 

このテーブルにおいて、以下の文は、

INSERT INTO t1 VALUES(NULL,123); 

論理的には、以下のように言うのと同じです。

INSERT INTO t1 VALUES((SELECT max(a) FROM t1)+1,123); 

これは、 sqlite3_last_insert_rowid() という名前の関数であり、最も最近の挿入操作の整数キーを返します。

整数キーは、その挿入の直前にテーブルにあった最大のキーよりも一つ大きいことに注意下さい。その新しいキーは今テーブルにあるすべてのキーの中で一意となるでしょう。しかし、そのテーブルから以前に削除されたキーと重なることがあります。そのテーブルの生涯でずっと一意のキーを作成するには、

INTEGER PRIMARY KEY 宣言に、AUTOINCREMENT キーワードを加えて下さい。そうすれば、選ばれたキーはそのテーブルにかつて存在した最大キー値よりも一つ大きいでしょう。もし可能な最大キーが以前にそのテーブルに存在したならば、その INSERT は SQLITE_FULL エラーコードで失敗します。

（２） SQLite はどんなデータ型をサポートしますか？

SQLite は ダイナミック型付けを使います。コンテンツは、 INTEGER, REAL, TEXT, BLOB, もしくは NULL として格納されることができます。

（３）SQLite は整数型のデータベースカラムに文字列を挿入することを許します！

これは機能です。バグではありません。SQLite は ダイナミック型付けを使います。それは、データ型制約を強制しません。どのような型のデータも（普通は）どのカラムにも入れることができます。任意の長さの文字列を整数カラムに、浮動小数点数をブーリアンのカラムに、あるいは日付を文字カラムに入れることができます。あなたが、CREATE TABLE コマンドでカラムに与えたデータ型は、そのカラムにどんなデータを入れることができるかを制限しません。全てのカラムは任意の長さの文字列を入れることができます。（例外が一つあります。 INTEGER PRIMARY KEY 型のカラムは、６４ビット符号付整数だけを入れることができます。 INTEGER PRIMARY KEY カラムに、整数以外のものを入れようとすると、エラーになります。）

しかし、SQLite はカラムの宣言された型を、あなたがその形式の値を望むというヒントとして実際に使います。なので、例えば、もしカラムの型が INTEGER で、あなたが文字列をそのカラムに入れようとすると、SQLite はその文字列を数字に変換しようとします。もしそれができれば、その代わりに整数を入れます。できなければ、文字列を入れます。この機能は、型アフィニティと呼ばれます。

（４）なぜ、SQLite は私が同じテーブルの二つの異なる行のプライマリキーとして、'0' と '0.0' を使うのを許さないのですか？

この問題は、あなたのプライマリキーが数字型の時に起きます。あなたのプライマリキーのデータ型を、TEXT に変えてください。そうすれば、うまくいきます。

全ての行は一意のプライマリキーを持たなくてはいけません。数字型のカラムにおいて、SQLite は '0' と '0.0' は同じ値だと思います。なぜならばそれらは数字として、等しいからです。（前の質問を見てください。）なので、値は一意ではありません。

（５）複数のアプリケーションもしくは、同じアプリケーションの複数のインスタンスは、同時に、単一のデータベースファイルをアクセスできますか？

複数のプロセスは、同じデータベースを同時にオープンしていることができます。複数のプロセスは、同時に、SELECT をしていることができます。しかし、いかなる時も、ただひとつのプロセスだけが、データベースに変更を加えることができます。

SQLite は、データベースへのアクセスを制御するために、リーダー／ライターロックを使います。（Win95/98/ME は、リーダー／ライターロックのサポートが無いので、その代わりに確率的なシミュレーションが使われます。）しかし注意して下さい。このロック機構は、もしデータベースファイルが NFS ファイルシステムに置かれているならば、正しく動かないことがあります。これは、多くの NFS 実装において fcntl() ファイルロックがこわれているからです。もし複数のプロセスが SQLite データベースファイルを同時にアクセスしようとすることがあるならば、それを NFS に置くのは避けるべきです。Windows では、マイクロソフトの文書は、あなたが Share.exe デーモンを動かしていない時は、 FAT ファイルシステムでは動かないことがあると言っています。Windows について多くの経験を持っている人々は、ネットワークファイルのファイルロックはとてもバグが多いので頼りにならないと私に告げました。もし彼らの言うことが正しいならば、SQLite データベースを２つ以上の Windows マシンで共有することは予期しない問題を起こすかもしれません。

私達は、SQLite 以上の並列同時実行性をサポートする組み込み SQL データベースエンジンを他に知りません。SQLite は、同時に複数のプロセスがデータベースファイルをオープンしているのを許します。そして、複数のプロセスがそのデータベースファイルを読むことも許します。どれかのプロセスがライトをしたい時は、それは自分の更新の間、データベースファイル全体をロックしなくてはいけません。しかしそれは通常は数ミリ秒しかかかりません。他のプロセスはそのライターが終わるのをただ待って、自分の仕事を続けます。他の組み込み SQL データベースエンジンは典型的には、同時にひとつのプロセスがデータベースに接続することしか許しません。

しかし、クライアント／サーバデータベースエンジン（PostgreSQL, MySQL, あるいは Oracle のような）は通常はより高いレベルの並列同時実行性をサポートし、複数のプロセスが同時に同じデータベースに書いているのを許します。これはクライアント／サーバデータベースにおいて可能です。なぜならば、常に、単一のよく制御されたサーバプロセスがいて、アクセスを調整できるからです。もしあなたのアプリケーションが多くの並列同時実行性を必要とするならば、あなたはクライアント／サーバデータベースを使うことを考えるべきです。しかし、経験は、ほとんどのアプリケーションは、その設計者が想像するよりずっと少ない並列同時実行性しか必要としないことを示唆します。

SQLite が他のプロセスがロックしているファイルをアクセスしようとした時、デフォルトのふるまいは、SQLITE_BUSY を返すことです。このふるまいを C コードから変えるには、sqlite3_busy_handler() あるいは sqlite3_busy_timeout() API を使って下さい。

（６）SQLite はスレッドセーフですか？

スレッドは邪悪です。避けなさい。

SQLite はスレッドセーフです。私達はこの譲歩をします。なぜならば、多くのユーザが、前のパラグラフで与えた忠告を無視するのを選ぶからです。しかし、スレッドセーフになるために、SQLite は SQLITE_THREADSAFE プリプロセッサマクロを１にしてコンパイルされなくてはいけません。ディストリビューションにある、あらかじめコンパイルされたバイナリは Windows のものも Linux のものも、こうしてコンパイルされています。もしあなたが、ご自分がリンクしている SQLiteライブラリがスレッドセーフであるようにコンパイルされているかどうかわからない時は、 sqlite3_threadsafe() インタフェースを呼んで調べることができます。

SQLite は、共通のデータ構造へのアクセスをシリアライズするためにミューテックスを使っているためにスレッドセーフです。しかし、これらのミューテックスを取ったり放したりする作業は、少し SQLiteを遅くします。なので、もしあなたが、SQLiteがスレッドセーフであることを必要としないならば、最大の性能を得るためにミューテックスを無効にするべきです。詳しくは、スレッドモデル文書を参照下さい。

Unix では、fork() システムコールをまたがって、子プロセスに開いたままの SQLite データベースを持っていってはいけません。

（７）SQLite データベースに含まれるテーブルとインデックスの一覧を得るにはどうしますか。

もしあなたが、sqlite3 コマンドラインアクセスプログラムを動かしているならば、".tables" を使えばすべてのテーブルの一覧が得られます。あるいは、".schema" をタイプして、すべてのテーブルとインデックスを含む完全なデータベーススキーマを見ることができます。これらコマンドのどちらにも、 LIKEパターンをつけて、表示されるテーブルを制限することができます。

C/C++ プログラム (あるは Tcl/Ruby/Perl/Python バインディングを使うスクリプト）からは、テーブルとインデックスの名前へのアクセスは、"SQLITE_MASTER" という名前の特別なテーブルへ SELECT を行うことで得られます。すべての SQLite データベースは、そのデータベースのためのスキーマを定義する SQLITE_MASTER テーブルを持ちます。SQLITE_MASTER テーブルは、このように見えます。

CREATE TABLE sqlite_master (   type TEXT,   name TEXT,   tbl_name TEXT,   rootpage INTEGER,   sql TEXT ); 

テーブルで、 type フィールドは常に 'table' であり、 name フィールドはそのテーブルの名前です。なので、データベースにあるすべてのテーブルの一覧を得るには、以下の SELECT コマンドを使います。

SELECT name FROM sqlite_master WHERE type='table' ORDER BY name; 

インデックスの場合、 type は 'index' に等しく、 name はそのインデックスの名前で、 tbl_name はそのインデックスが属するテーブルの名前です。テーブルとインデックスにおいて、 sql フィールドは、そのテーブルあるいはインデックスを作った、元の CREATE TABLE あるいは CREATE INDEX 文です。自動的に作られたインデックス (PRIMARY KEY あるいは UNIQUE 制約を実装するために作られた) の場合、 sql フィールドは NULL です。

SQLITE_MASTER テーブルはリードオンリーです。このテーブルを、UPDATE, INSERT, あるいは DELETE を使って変更することはできません。このテーブルは、CREATE TABLE, CREATE INDEX, DROP TABLE, そして DROP INDEX コマンドによって自動的に更新されます。

一時的テーブルは SQLITE_MASTER テーブルには現れません。一時的テーブルとそのインデックスそしてトリガーは、SQLITE_TEMP_MASTER と呼ばれる他の特別のテーブルに現れます。SQLITE_TEMP_MASTER は、SQLITE_MASTER と同じようにはたらきます。ただ、それはその一時的テーブルを作ったアプリケーションにだけ見えます。永続的と一時的の両方のすべてのテーブルの一覧を得るには、以下のようなコマンドを使うことができます。

SELECT name FROM     (SELECT * FROM sqlite_master UNION ALL     SELECT * FROM sqlite_temp_master) WHERE type='table' ORDER BY name

（８）SQLite データベースには、既知の大きさの制限が何かありますか？

SQLite の限界について完全な議論は、limits.html を参照下さい。

（９）SQLite において、VARCHAR の最大長はいくつですか？

SQLite は、VARCHAR の長さを制限しません。 あなたは、

VARCHAR(10) を宣言して、SQLite は喜んで、５億文字の文字列をそこに格納することができます。そしてそれは、全ての５億文字の文字をそのままに保持できます。 

あなたのコンテンツは切り詰められません。SQLite は、"VARCHAR(N)" 型のカラムを、N の値にかかわらず、"TEXT" と同じであると理解します。

（１０）SQLite は BLOB 型をサポートしますか？

SQLite は どのカラムに BLOB データを入れることも許します。そのカラムが他の型を持つように定義されている場合にもです。

BLOB を PRIMARY KEY に使うことさえできます。

（１１）SQLite の既存のテーブルに、カラムを追加削除するにはどうしますか？

SQLite は、ALTER TABLE の制限されたサポートを持ちます。これであなたは、テーブルの終わりにカラムを追加したり、テーブルの名前を変えたりできます。

それ以上の複雑な変更をテーブルの構造に対してしたい時は、テーブルを作り直す必要があります。今あるデータを一時的なテーブルに退避して、

古いテーブルをドロップし、新しいテーブルを作成し、そして一時的なテーブルからデータをコピーして戻します。

例えば、あなたが、"t1" という名前のテーブルを持ち、そのカラム名が "a", "b", そして "c" とします。あなたはカラム "c" をこのテーブルから削除したいです。以下のステップは、これを行う方法を示します。

BEGIN TRANSACTION;

CREATE TEMPORARY TABLE t1_backup(a,b);

INSERT INTO t1_backup SELECT a,b FROM t1;

DROP TABLE t1;

CREATE TABLE t1(a,b);

INSERT INTO t1 SELECT a,b FROM t1_backup;

DROP TABLE t1_backup;

COMMIT;

（１２）私は多くのデータを削除しました。しかし、データベースファイルは少しも小さくなりません。これはバグですか？ 

いいえ。あなたが SQLite データベースから情報を削除するとき、使われないディスク領域は、内部的な「空きリスト」に加わります。

そして、次にデータを挿入するときに再使用されます。そのディスク領域は失われません。しかし、オペレーティングシステムに返されることもありません。

もしあなたが多くのデータを削除し、データベースファイルを小さくしたいならば、VACUUM

コマンドを使ってください。VACUUM は、ゼロからデータベースを再構築します。

この結果、データベースは空の空きリストを持ち、ファイルは最小の大きさとなります。しかし、注意ください。

VACUUM は、実行するのにしばらくかかり、それが実行中は、元のファイルの二倍の大きさの一時的ディスク領域を使うことがあります。

VACUUM コマンドを使う代わりに、auto_vacuum pragma を使って、自動バキュームモードを有効にすることもできます。

（１３）私は、SQLite を、私の商用製品に、ロイヤリティを払わないで使うことができますか？

はい。SQLite isは パブリックドメインにあります。コードのどの部分にも、所有権の主張は行われません。あなたは、それでご自分がしたいことを何でもできます。

（１４）シングルクォート文字(')が埋め込まれた文字列リテラルを使うにはどうしますか？

SQL 標準は、文字列中のシングルクォートは二つのシングルクォートを続けて入れることでエスケープされると定めます。この点、SQL は Pascal プログラム言語と似たようにはたらきます。

例：

 INSERT INTO xyz VALUES('5 O''clock');

(15) SQLITE_SCHEMA エラーとは何ですか、なぜ私はこれを得るのですか？

SQLITE_SCHEMA エラーは、準備された SQL 文がもう有効でなく、実行できないときに返ります。これが起きたら、その文は SQL から、sqlite3_prepare() API を使って再コンパイルされなくてはいけません。SQLITE_SCHEMA エラーは、SQL を実行するのに、 sqlite3_prepare(), と sqlite3_step() インタフェースを使っているときにだけ起きます。sqlite3_exec() からは、SQLITE_SCHEMA エラーは決して起きません。 また、あなたが、文を、sqlite3_prepare() でなく、 sqlite3_prepare_v2() で準備するときにも、このエラーは起きません。

sqlite3_prepare_v2() インタフェースは、スキーマが変わったら自動的に自分をコンパイルしなおす 被準備文を作成します。 SQLITE_SCHEMA エラーに対処するもっとも簡単な方法は、sqlite3_prepare() でなく、 常に sqlite3_prepare_v2() を使うことです。

（１６）なぜ、 ROUND(9.95,1) は 10.0 でなく 9.9 を返すのですか？ 9.95 は切り上がるべきでないですか？

SQLite は二進数演算を使います。そして、二進数では、 9.95 を有限のビット数で書く方法はありません。64-bit IEEE float (SQLite はそれを使います) で、 9.95 に一番近いのは、 9.949999999999999289457264239899814128875732421875 です。なので、あなたが "9.95" とタイプするとき、SQLite は本当はその数字を、前記のずっと長い値として理解します。そしてその値は、切り下がります。

この種類の問題は、浮動小数点二進数を扱う時にいつでも起きます。覚えておくべき一般規則は、１０進数（"base-10"とも呼ばれます）で有限の表現を持つほとんどの小数は、二進数（"base-2"とも呼ばれます）では、有限の表現を持たないということです。なのでそれらは、最も近い二進数で近似されます。この近似は通常はとても近いですが、少しずれることもあり、場合によってはあなたの結果を、あなたが期待するものと少し違うようにすることもあります。

（１７）私がSQLite をコンパイルしたら、コンパイラの警告がいくつか出ました。これは問題ですか？コードの品質が悪いことを意味するのではないですか？

SQLite での品質保証は、完全なカバレッジテストを使って行われます。コンパイラ警告や、ほかの静的コード解析ツールによるのではありません。言葉を代えて言えば、私たちは、SQLite が実際に正しい答えを返すことを検証します。それが文体上の制約を満足すれば良いとは考えません。多くの SQLite のコードベースは、純粋にテストのためだけにあります。SQLite テストスイートは、数万の独立したテストケースを流します。そしてこれらのテストケースの多くはパラメタ付けされています。このため、数十億の SQL 文を伴う、数億のテストが、全てのリリースの前に実行され、正しいことが評価されます。開発者は、コードカバレッジツールを使ってコードの全てのパスがテストされたことを確認します。SQLite でバグが見つかったときは、そのバグを明らかにするために新しいテストケースが書かれ、将来そのバグが知らないうちに再発するのを防ぎます。

テストの間、SQLite ライブラリは特別なインストゥルメンテーションをつけてコンパイルされます。それは、テストスクリプトが、いろいろな種類の障害をシミュレートして、SQLite が正しく回復できることを確認するためです。メモリ確保は注意深く追跡されます。そして、メモリ確保の失敗の後であっても、メモリリークは起きません。特別に作られた VFS 層が、オペレーティングシステムのクラッシュと電源喪失をシミュレートするために使われ、トランザクションがこれらのイベントをまたがってもアトミックであることを確認します。注意深く I/O エラーを注入する機構は、SQLite がそのような障害に耐えることを示します。（実験として、これらの種類のエラーを、他の SQL データベースエンジンに起こすことを試してみて、何が起きるか見てください！）

私たちは、Linux で Valgrind を使って、SQLite を動かすこともします。問題が見つからないことを確認します。

全ての警告を除くべきだと言う人々もいます。無害な警告は、将来の変更で起きるかもしれない、本当の警告をマスクするからです。それは確かに正しいです。しかし、それに対しては、開発者は、SQLite の開発で使われるビルド（いろいろなバージョンの、GCC, MSVC, そして clang）において、全ての警告は修正されたことを確認しています。コンパイラの警告は、SQLite 開発者が自分では使わないコンパイラや、コンパイル時のオプションの下でだけ通常は発生します。

（１８）大文字小文字を区別しないユニコードの比較が動きません。

SQLite のデフォルトの設定は、大文字小文字を区別しないアスキー文字の比較だけをサポートします。その理由は、大文字小文字を区別するユニコードの完全な比較とケースの変換をすることは、SQLite ライブラリの大きさを、ほぼ倍にするテーブルと論理を必要とするからです。SQLite 開発者は、完全なユニコードのケースのサポートを必要とするアプリケーションはすべて、たぶん既に必要なテーブルと関数を持っているだろうと推測しました。なので、SQLite はその能力を重複するために、場所をとるべきでないでしょう。

デフォルトで完全なユニコードのケースをサポートする代わりに、SQLite は外部のユニコード比較と変換ルーチンに対してリンクする能力を提供します。 アプリケーションは、ビルトインの NOCASE 照合シーケンスをオーバーロードすることができます (sqlite3_create_collation() を使います)。そして、ビルトインの like(), upper(), そして lower() 関数も (sqlite3_create_function() を使います)。SQLite ソースコードは、このオーバーロードを行う "ICU" 拡張を含みます。あるいは、開発者は、ご自分のプロジェクトにすでに含まれる、ユニコードを意識したご自分独自の比較ルーチンに基づくオーバーロードを書くこともできます。

（１９）INSERTがとても遅いです -  一秒に数十個の INSERT しかできません。

実際には、SQLite は、平均的なデスクトップ計算機で、簡単に、 50,000 以上の INSERT 文を実行できます。しかしそれは、毎秒数十個のトランザクションしか実行できません。トランザクションの速度はあなたのディスクドライブの回転速度によって制限されます。トランザクションは通常は、二回の完全なディスク円盤の回転を必要とします。それは、7200RPM のディスクドライブであなたを毎秒約６０トランザクションに制限します。

トランザクションの速度は、ディスクドライブの速度に制限されます。なぜならば、（デフォルトで）SQLite は、トランザクションが完了する前にデータが本当にディスク表面に安全に格納されるのを実際に待つからです。そうすることで、もし電源が突然落ちたり、あなたの OS がクラッシュしても、あなたのデータは安全なままなのです。詳しくは、 SQLite でのアトミックコミットを読んで下さい。

デフォルトで、それぞれの INSERT 文は自分自身のトランザクションです。しかしもしあなたが、複数の INSERT 文を BEGIN...COMMIT で囲むと、すべての挿入は単一のトランザクションにまとめられます。トランザクションをコミットするのに必要な時間は、含まれるすべての INSERT 文に分散されますから、ひとつの INSERT 文ごとの時間は大いに減ります。

もうひとつのオプションは、PRAGMA synchronous=OFF を実行することです。このコマンドは、SQLite がデータがディスク表面に届くのを待たないようにします。それは、ライト操作をずっと速く見せます。しかしトランザクションの途中で電源が落ちたら、あなたのデータベースファイルはこわれるかもしれません。

（２０）私は誤って、重要な情報を私の SQLite データベースから削除しました。それを回復するにはどうしたらいいですか？

もしあなたがあなたのデータベースファイルのバックアップコピーをお持ちなら、バックアップからその情報を回復ください。

バックアップがない場合、回復はとても難しいです。生のデータベースファイルのバイナリダンプの中から、部分的な文字列のデータを見つけることはできるかもしれません。なんらかの特殊なツールがあれば、数字データを回復することもできるかもしれません。しかし私たちの知る限り、そのようなツールはありません。SQLite は、SQLITE_SECURE_DELETE オプションつきでコンパイルされることがあります。それは、全ての削除したコンテンツをゼロで上書きします。その場合、回復は明らかに不可能です。あなたがデータを消した後で VACUUM を実行した場合も、回復は不可能です。SQLITE_SECURE_DELETE が使われておらず、VACUUM も実行されていないならば、削除されたコンテンツのいくらかは、今でも、データベースファイルの、再使用とマークされた領域にあるかもしれません。しかし、繰り返しますが、私たちの知る限り、あなたがそのデータを回復する助けとなる手続きやツールはありません。

(21) SQLITE_CORRUPT エラーとは何ですか？ データベースが "malformed" であるとはどういう意味ですか？なぜ私はこのエラーを得るのですか？

SQLITE_CORRUPT エラーは、SQLite が構造体、形式、あるいはデータベースファイルの他の制御要素に誤りを検出したときに返されます。

SQLite は外部の要因がなければ、データベースファイルをこわしません。もしあなたのアプリケーションが更新の途中でクラッシュしても、あなたのデータは安全です。あなたのOSがクラッシュしても、電源を失った時にさえ、データベースは安全です。SQLite のクラッシュ耐久性は、大いに研究され、テストされ、何十億ものユーザによる何年にもわたる実世界での経験によって証明されています。

とは言え、外部プログラムや、あなたのハードウェアもしくはOSのバグが実際にデータベースファイルをこわすことはいくつか考えられます。くわしくは、 SQLite データベースファイルをこわすにはどうするかを参照下さい。

あなたは、 PRAGMA integrity_check を使って、完全ですが時間のかかるデータベースの整合性テストをできます。

あなたは、 PRAGMA quick_check を使って、高速ですがそれほど完全ではないデータベースの整合性テストをできます。

あなたは、CLI を使って、スキーマとコンテンツをダンプしてファイルに落とし、そして再作成することで、データの一部を回復することができることがあります。それは、あなたのデータベースがどのくらい悪くこわれているかに依存します。不幸なことに、一度、ハンプティダンプティが壁から落ちたら、一般的には彼をもう一度一つに戻すのは不可能です。

（２２）SQLite は外部キーをサポートしますか？

version 3.6.19 (2009-10-14) 現在、 SQLite は 外部キー制約をサポートします。しかし、外部キー制約の強制は、デフォルトでは無効にされています（後方互換性のため）。外部キー制約を有効にするには、 PRAGMA foreign_keys=ON を実行するか、-DSQLITE_DEFAULT_FOREIGN_KEYS=1 をつけてコンパイル下さい。

（２３）SQLite をビルドするときに、SQLITE_OMIT_...  コンパイル時オプションを使うと、コンパイルエラーになります。

SQLITE_OMIT_... コンパイル時オプションは、正統的ソースファイルからビルドするときにしかはたらきません。あなたが、SQLite amalgamation や、プリプロセスされたソースファイルからビルドするときにははたらきません。

あらかじめ定められた SQLITE_OMIT_... オプションのセットとともにはたらく特別な amalgamation を作ることが可能です。そのための指示は、SQLITE_OMIT_... 文書 にあります。

（２４）私の、 WHERE 節の表現、column1="column1" がはたらきません。column1 が、 "column1" という値を持つ行だけでなく、テーブルの全ての行が返ります。

SQL では、文字列リテラルのまわりに、ダブルクォートでなくシングルクォートを使ってください。これが、SQL 標準が要求することです。あなたの WHERE 節の表現は、column1='column1' であるべきです。

SQL は、特別文字を含む識別子（カラムやテーブル名）あるいは、キーワードである識別子のまわりに、ダブルクォートを使います。なので、ダブルクォートは識別子名をエスケープする方法です。この結果、あなたが column1="column1" と言う時それは、column1=column1 に等しく、それは明らかに常に真です。

（２５）SQLite のシンタックスダイアグラム（「路線図」とも呼ばれます）は、どのように生成されるのですか？

http://wiki.tcl-lang.org/21708 で、そのプロセスが説明されます。

（２６） SQL 標準は、UNIQUE 制約において、もし制約に含まれる一つ以上のカラムが NULL であっても、制約は強制されることを要求します。しかし、SQLite はこれをしません。これはバグではないですか？

たぶん、あなたは、SQL92 の以下の文章を参照しているのでしょう。

一意性の制約は、あるテーブルの二つの行が、一意のカラムにおいて、ヌルでない同じ値を持たない時にだけ満足されます。

この文章はあいまいです。少なくても、二つの可能な解釈があります。

１． 一意性の制約は、あるテーブルの二つの行が、一意のカラムにおいて、同じ値を持たず、ヌルでない値を持つ時にだけ満足されます。

２． 一意性の制約は、あるテーブルの二つの行が、ヌルでない一意のカラムのサブセットにおいて、同じ値を持たない時にだけ満足されます。

SQLite は、（１）の解釈に従います。PostgreSQL, MySQL, Oracle, そして Firebird もそうです。Informix と Microsoft SQL Server が（２）の解釈を使うのは事実です。しかし、私たち SQLite の開発者は、（１）の解釈が要件の最も自然な読み方であるという立場をとります。そして私たちは他の SQL データベースエンジンと最大限の互換性を取りたいと思っています。他のほとんどのデータベースエンジンは（１）で行きます。なので、それが SQLite がすることです。

（２７）SQLite の、Export Control Classification Number (ECCN) は何ですか？

Commerce Control List (CCL) を注意深く調べた結果、私たちは、コアであるパブリックドメインの SQLite のソースコードは、いかなる ECCN によっても記述されないことを確信しました。このため、ECCN は、EAR99 として報告されるべきです。

以上は、コアであるパブリックドメインの SQLite に対して真です。もしあなたが SQLiteに新しいコードを加えて拡張したり、あなたが SQLite をあなたのアプリケーションに静的リンクしたならば、あなた固有の場合において、ECCN は変わるかもしれません。

（２８）私の問い合わせは、期待したカラム名を返しません。これはバグですか？

もし、あなたの結果セットのカラムが、AS 節で名前が与えられたのであれば、SQLite は AS キーワードの右にある識別子をカラム名として使うことが保証されます。もし結果セットが AS 節を使わないならば、SQLite はそのカラムを、自分の好きな名前にします。詳しくは、 sqlite3_column_name() 文書を参照下さい。

以上