DISQLite3 Pro破解版 v5.21.0 免費版Delphi控件

DISQLite3 Pro破解版是一款非常專業(yè)的Delphi控件，而且使用DISQLite3創(chuàng)建的數(shù)據(jù)庫文件也可以由Linux和MacOS使用SQLite3庫訪問，下面小編為大家?guī)砥平獍?，有需要的歡迎下載！

軟件介紹

DISQLite3 Pro破解版是一款功能起那個大的SQL數(shù)據(jù)庫引擎管理軟件，實現(xiàn)了一個自包含的，可嵌入的，零配置的SQL數(shù)據(jù)庫引擎，無需進行過多的設(shè)置或管理，DISQLite3基于流行的SQLite3數(shù)據(jù)庫引擎的源代碼庫。因此，DISQLite3繼承了SQLite3的所有功能。它像SQLite3一樣打開，讀取和修改SQLite3數(shù)據(jù)庫文件。使用DISQLite3創(chuàng)建的數(shù)據(jù)庫文件與SQLite3完全兼容，包括非Windows平臺。它可實現(xiàn)大多數(shù)SQL-92，能夠完整的數(shù)據(jù)庫存儲在單個磁盤文件中。除此之外，還包括全文搜索(FTS)，可定制的標記器，前綴匹配，以及15種語言的可選字詞等功能，可使用SHA256密鑰發(fā)生器的數(shù)據(jù)庫AES加密。

軟件安裝破解教程

1、在本站下載并解壓，如圖所示，獲得一個DISQLite3_5.21.0.exe安裝程序和Crack破解文件夾

2、雙擊DISQLite3_5.21.0.exe運行，進入安裝向?qū)?，點擊next

3、點擊瀏覽選擇安裝路徑，點擊install安裝

4、安裝完成后，先不要啟動，將crack破解文件夾中的文件復(fù)制到軟件安裝目錄中，點擊替換目標中的文件

軟件特色

ACID事務(wù)，即使在系統(tǒng)崩潰和電源故障之后。

零配置 - 無需設(shè)置或管理。

實現(xiàn)大多數(shù)SQL-92。

完整的數(shù)據(jù)庫存儲在單個磁盤文件中。

支持千兆字節(jié)大小的數(shù)據(jù)庫和千兆字節(jié)大小的字符串和字符串。自包含：沒有外部依賴，沒有DLL。

小尺寸和智能鏈接：只需編譯所需的代碼，僅添加300 KB的代碼空間。

全文搜索(FTS)，可定制的標記器，前綴匹配，以及15種語言的可選字詞。

使用SHA256密鑰發(fā)生器的數(shù)據(jù)庫AES加密。

Db.pas 是不需要的，它允許DISQLite3編譯所有的Delphi，包括Delphi Standard和Delphi Personal。

比普遍的數(shù)據(jù)庫引擎更適合大多數(shù)常見操作。

簡單易用的API。

使用DISQLite3創(chuàng)建的數(shù)據(jù)庫文件也可以由Linux和MacOS使用SQLite3庫訪問。

SQL-92支持

DISQLite3驅(qū)動目錄演示應(yīng)用程序DISQLite3了解大多數(shù)SQL-92語言標準：

ALTER TABLE

分析

ATTACH數(shù)據(jù)庫

開始交易

注釋

提交交易

創(chuàng)建索引

創(chuàng)建表

創(chuàng)建觸發(fā)器

創(chuàng)建視圖

刪除

DETACH數(shù)據(jù)庫

DROP INDEX

DISQLite3數(shù)學(xué)表達式求值程序演示應(yīng)用程序DROP TABLE

DROP觸發(fā)器

DROP VIEW

終止交易

說明

表達式

插

ON CONFLICT子句

PRAGMA

REINDEX

更換

滾動交易

選擇

UPDATE

簡單的編程接口

DISQLite3數(shù)據(jù)庫加密演示應(yīng)用程序DISQLite3提供了一個功能和過程的全面列表，以便輕松高效地管理數(shù)據(jù)庫記錄。它包括完整的SQLite3功能，還有一些Delphi特定的附加功能：

AnsiString，UnicodeString / WideString和Variant支持。

數(shù)據(jù)庫和語句包裝類。

TDataSet支持。

TStream支持BLOB。

越來越多的Delphi示例項目。

盡管功能豐富，但只有三個不同的函數(shù)調(diào)用可以實現(xiàn)DISQLite3數(shù)據(jù)庫應(yīng)用程序。

主要特色

ACID事務(wù)，即使在系統(tǒng)崩潰和電源故障之后。

零配置 - 無需設(shè)置或管理。

實現(xiàn)大多數(shù)SQL-92。

完整的數(shù)據(jù)庫存儲在單個磁盤文件中。

支持千兆字節(jié)大小的數(shù)據(jù)庫和千兆字節(jié)大小的字符串和字符串。

小尺寸和智能鏈接：只需編譯所需的代碼，僅添加300 KB的代碼空間。

全文搜索(FTS)，可定制的標記器，前綴匹配，以及15種語言的可選字詞。

使用SHA256密鑰發(fā)生器的數(shù)據(jù)庫AES加密。

Db.pas 是不需要的，它允許DISQLite3編譯所有的Delphi，包括Delphi Standard和Delphi Personal。

比普遍的數(shù)據(jù)庫引擎更適合大多數(shù)常見操作。

簡單易用的API。

使用DISQLite3創(chuàng)建的數(shù)據(jù)庫文件也可以由Linux和MacOS使用SQLite3庫訪問。

常見問題

1.我如何創(chuàng)建一個AUTOINCREMENT字段

簡短回答：聲明INTEGER PRIMARY KEY的列將自動增加。

下面是一個很長的答案：如果你將一個表的列聲明為INTEGER PRIMARY KEY，那么只要你在表中插入一個NULL值，NULL就會自動轉(zhuǎn)換成一個大于最大值的整數(shù)該列在表中的所有其他行上，如果該表為空，則為1。 (如果已經(jīng)使用了最大可能的整數(shù)密鑰9223372036854775807，則隨機選擇一個未使用的密鑰值。)例如，假設(shè)您有一個如下所示的表：

CREATE TABLE t1(

INTEGER PRIMARY KEY，

b INTEGER);

用這個表格，聲明

INSERT INTO t1 VALUES(NULL，123);

在邏輯上相當于說：

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

唯一鍵將按順序進行，直到最大鍵達到最大64位有符號整數(shù)的值。該值不能遞增，因此后續(xù)的插入嘗試將使用半隨機密鑰生成算法。

有一個函數(shù)sqlite3_last_insert_rowid，它將返回最近插入操作的整數(shù)鍵。

請注意，整數(shù)鍵比插入前表中最大的鍵大1。新密鑰對于當前表中的所有密鑰都是唯一的，但它可能與之前從表中刪除的密鑰重疊。要創(chuàng)建在表的生命周期內(nèi)唯一的鍵，請將AUTOINCREMENT關(guān)鍵字添加到INTEGER PRIMARY KEY聲明中。那么所選的關(guān)鍵將是比該表中曾經(jīng)存在的最大關(guān)鍵要多一個。如果該表中以前存在最大可能的鍵，那么INSERT將失敗并顯示SQLITE_FULL錯誤代碼。

2.DISQLite3支持哪些數(shù)據(jù)類型?

請參閱數(shù)據(jù)類型。

DISQLite3允許我將一個字符串插入到integer類型的數(shù)據(jù)庫列中!

這是一個功能，而不是一個錯誤。 DISQLite3不執(zhí)行數(shù)據(jù)類型約束。任何數(shù)據(jù)都可以插入到任何列中。您可以將任意長度的字符串放入整數(shù)列，布爾列中的浮點數(shù)或字符列中的日期。您在CREATE TABLE命令中分配給列的數(shù)據(jù)類型不限制可將哪些數(shù)據(jù)放入該列。每列可以容納任意長度的字符串。 (有一個例外：INTEGER PRIMARY KEY類型的列只能包含64位有符號整數(shù)，如果您嘗試將除INTEGER PRIMARY KEY列之外的其他任何內(nèi)容放入INTEGER PRIMARY KEY列，則會導(dǎo)致錯誤。)

但是，DISQLite3確實使用列的聲明類型作為您偏好該格式的值的提示。因此，例如，如果列的類型為INTEGER，并且您嘗試將字符串插入該列，則DISQLite3將嘗試將該字符串轉(zhuǎn)換為整數(shù)。如果可以，它會插入整數(shù)。如果不是，則插入字符串。此功能有時稱為類型親和力。

3.為什么DISQLite3不允許我在同一個表的兩個不同行上使用'0'和'0.0'作為主鍵?

當您的主鍵是數(shù)字類型時，會發(fā)生此問題。將主鍵的數(shù)據(jù)類型更改為TEXT，它應(yīng)該可以工作。

每一行都必須有一個唯一的主鍵。對于具有數(shù)字類型的列，DISQLite3認為'0'和'0.0'是相同的值，因為它們的比較數(shù)值相等。 (請參閱上一個問題。)因此，這些值不是唯一的。

4.多個應(yīng)用程序或同一應(yīng)用程序的多個實例可以同時訪問單個數(shù)據(jù)庫文件嗎?

多個進程可以同時打開同一個數(shù)據(jù)庫。多個進程可以同時做一個SELECT。但是，只有一個過程可以在任何時間對數(shù)據(jù)庫進行更改。

DISQLite3使用讀寫器鎖來控制對數(shù)據(jù)庫的訪問。 (在Win95 / 98 / ME下，缺少對讀/寫鎖的支持，而是使用概率模擬。)但要小心：如果數(shù)據(jù)庫文件保存在NFS文件系統(tǒng)上，則此鎖定機制可能無法正常工作。這是因為在許多NFS實現(xiàn)中fcntl()文件鎖定被破壞。如果多個進程可能嘗試同時訪問文件，則應(yīng)該避免將DISQLite3數(shù)據(jù)庫文件放在NFS上。在Windows上，Microsoft的文檔說如果您沒有運行Share.exe守護進程，鎖定可能無法在FAT文件系統(tǒng)下運行。對Windows有很多經(jīng)驗的人告訴我，網(wǎng)絡(luò)文件的文件鎖定非常麻煩并且不可靠。如果他們說的是真的，在兩臺或多臺Windows機器之間共享DISQLite3數(shù)據(jù)庫可能會導(dǎo)致意外問題。

我們知道沒有其他嵌入式SQL數(shù)據(jù)庫引擎支持與DISQLite3一樣多的一致性。 DISQLite3允許多個進程一次打開數(shù)據(jù)庫文件，并允許多個進程一次讀取數(shù)據(jù)庫。當任何進程想要寫入時，它必須在更新期間鎖定整個數(shù)據(jù)庫文件。但通常只需要幾毫秒。其他流程只是等待作者完成，然后繼續(xù)他們的業(yè)務(wù)。其他嵌入式SQL數(shù)據(jù)庫引擎通常只允許一個進程同時連接到數(shù)據(jù)庫。

但是，客戶端/服務(wù)器數(shù)據(jù)庫引擎(如PostgreSQL，MySQL或Oracle)通常支持更高級別的并發(fā)，并允許多個進程同時寫入同一數(shù)據(jù)庫。這在客戶端/服務(wù)器數(shù)據(jù)庫中是可行的，因為總是有一個可以協(xié)調(diào)訪問的良好控制的服務(wù)器進程。如果您的應(yīng)用程序需要大量的并發(fā)性，那么您應(yīng)該考慮使用客戶端/服務(wù)器數(shù)據(jù)庫。但是經(jīng)驗表明，大多數(shù)應(yīng)用程序所需要的并發(fā)性比設(shè)計者想象的要少得多。

5.DISQLite3線程安全嗎?

DISQLite3默認編譯為線程安全。這可以在編譯時通過重新編譯DISQLite3源代碼，在開始時調(diào)用sqlite3_config或在調(diào)用sqlite3_open_v2時的運行時進行更改。

默認的線程模式是“序列化”，并允許應(yīng)用程序同時使用來自多個線程的同一數(shù)據(jù)庫連接。

只要連接沒有鎖，應(yīng)用程序就可以通過線程移動連接句柄。如果沒有事務(wù)處于掛起狀態(tài)并且所有語句都已完成，則可以安全地假定沒有鎖被保留。

6.如何列出DISQLite3數(shù)據(jù)庫中包含的所有表/索引?

您可以通過在名為“SQLITE_MASTER”的特殊表上執(zhí)行SELECT來訪問表和索引名稱。 每個DISQLite3數(shù)據(jù)庫都有一個定義數(shù)據(jù)庫模式的SQLITE_MASTER表。 SQLITE_MASTER表如下所示：

CREATE TABLE sqlite_master (

type TEXT,

name TEXT,

tbl_name TEXT,

rootpage INTEGER,

sql TEXT);

對于表格，類型字段將始終為'table'，名稱字段將為表格的名稱。 因此，要獲取數(shù)據(jù)庫中所有表的列表，請使用以下SELECT命令：

SELECT name FROM sqlite_master

WHERE type='table'

ORDER BY name;

對于索引，type等于'index'，name是索引的名稱，tbl_name是索引所屬表的名稱。對于表和索引，sql字段是創(chuàng)建表或索引的原始CREATE TABLE或CREATE INDEX語句的文本。對于自動創(chuàng)建的索引(用于實現(xiàn)PRIMARY KEY或UNIQUE約束)，sql字段為零。

SQLITE_MASTER表是只讀的。您無法使用UPDATE，INSERT或DELETE更改此表。該表由CREATE TABLE，CREATE INDEX，DROP TABLE和DROP INDEX命令自動更新。

臨時表不會出現(xiàn)在SQLITE_MASTER表中。臨時表及其索引和觸發(fā)器出現(xiàn)在另一個名為SQLITE_TEMP_MASTER的特殊表中。 SQLITE_TEMP_MASTER的工作方式與SQLITE_MASTER相似，只是它只對創(chuàng)建臨時表的應(yīng)用程序可見。要獲得所有永久和臨時表的列表，可以使用類似于以下的命令：

SELECT name FROM

(SELECT * FROM sqlite_master UNION ALL

SELECT * FROM sqlite_temp_master)

WHERE type='table'

ORDER BY name

7.DISQLite3數(shù)據(jù)庫是否有已知的大小限制?

點擊這里查看關(guān)于DISQLite3限制的完整討論。

8.DISQLite3中VARCHAR的最大大小是多少?

DISQLite3不強制執(zhí)行VARCHAR的長度。你可以聲明一個VARCHAR(10)，并且DISQLite3會很樂意讓你放入500個字符。它將保持所有500個字符的完整 - 它從不截斷。

9.DISQLite3是否支持BLOB類型?

DISQLite3允許您將BLOB數(shù)據(jù)存儲在任何列中，甚至是聲明為保存其他類型的列。

10如何在DISQLite3的現(xiàn)有表格中添加或刪除列?

DISQLite3具有有限的ALTER TABLE支持，您可以使用它將列添加到表的末尾或更改表的名稱。如果你對表的結(jié)構(gòu)做了更復(fù)雜的修改，你將不得不重新創(chuàng)建表。您可以將現(xiàn)有數(shù)據(jù)保存到臨時表中，刪除舊表，創(chuàng)建新表，然后將數(shù)據(jù)從臨時表中復(fù)制回來。

例如，假設(shè)您有一個名為“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;

ALTER TABLE t1_backup RENAME TO t1;

COMMIT;

11.我刪除了很多數(shù)據(jù)，但數(shù)據(jù)庫文件沒有變小。這是一個錯誤?

不可以。從DISQLite3數(shù)據(jù)庫刪除信息時，未使用的磁盤空間將添加到內(nèi)部“自由列表”中，并在下次插入數(shù)據(jù)時重新使用。磁盤空間不會丟失。但是它們都沒有返回到操作系統(tǒng)。

如果刪除大量數(shù)據(jù)并想縮小數(shù)據(jù)庫文件，請運行VACUUM命令。 VACUUM將從頭開始重建數(shù)據(jù)庫。這將使數(shù)據(jù)庫保留一個空白的自由列表和一個尺寸最小的文件。但是，請注意，VACUUM可能需要一些時間才能運行(每兆字節(jié)大約為半秒)，并且在運行時可以使用最多兩倍的臨時磁盤空間作為原始文件。

使用VACUUM命令的替代方法是使用auto_vacuum編譯指示啟用的auto-vacuum模式。

12.如何使用包含嵌入式單引號(')字符的字符串文字?

SQL標準指定通過在一行中放置兩個單引號來逃脫字符串中的單引號。在這方面，SQL就像Pascal編程語言一樣工作。 DISQLite3遵循這個標準。例：

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

13.什么是SQLITE_SCHEMA錯誤，為什么我會得到一個?

準備好的SQL語句不再有效并且無法執(zhí)行時，將返回SQLITE_SCHEMA錯誤。發(fā)生這種情況時，必須使用sqlite3_prepare API從SQL重新編譯該語句。只有在使用sqlite3_prepare / sqlite3_step / sqlite3_finalize API執(zhí)行SQL時才會發(fā)生SQLITE_SCHEMA錯誤，而不是在使用sqlite3_exec時發(fā)生。

準備好的語句變得無效的最常見原因是數(shù)據(jù)庫的模式在SQL準備好之后(可能由另一個進程)修改。這可能發(fā)生的其他原因是：

數(shù)據(jù)庫被DETACHed。

數(shù)據(jù)庫是VACUUMed。

用戶功能定義已被刪除或更改。

排序規(guī)則定義已被刪除或更改。

授權(quán)功能已更改。

在所有情況下，解決方案是從SQL重新編譯語句并嘗試再次執(zhí)行它。因為準備好的語句可能會被另一個更改數(shù)據(jù)庫模式的進程無效，所以使用sqlite3_prepare / sqlite3_step / sqlite3_finalize API的所有代碼都應(yīng)該準備好處理SQLITE_SCHEMA錯誤。

14.為什么ROUND(9.95,1)會返回9.9而不是10.0?不應(yīng)該9.95整理?

SQLite使用二進制算術(shù)，二進制，沒有辦法寫9.95在有限的位數(shù)。最接近你的可以達到9.95的64位IEEE浮點數(shù)(這是SQLite使用的)是9.949999999999999289457264239899814128875732421875。所以當你輸入“9.95”時，SQLite真的可以理解這個數(shù)字是上面顯示的數(shù)值。這個價值下降了。

處理浮點二進制數(shù)字時，這種問題始終存在。要記住的一般規(guī)則是，具有十進制的有限表示(a.k.a“base-10”)的大多數(shù)分數(shù)在二進制中沒有有限的表示(a.k.a“base-2”)。因此它們使用可用的最接近的二進制數(shù)來近似。這種近似值通常非常接近，但會略微偏離，在某些情況下可能導(dǎo)致結(jié)果與您預(yù)期的結(jié)果有所不同。

15.Unicode字符不區(qū)分大小寫的匹配不起作用。

SQLite的默認配置只支持不區(qū)分大小寫的ASCII字符比較。原因在于，要進行完整的不區(qū)分大小寫的比較和大小寫轉(zhuǎn)換，需要表和邏輯幾乎將SQLite庫的大小加倍。 SQLite開發(fā)人員認為，任何需要完整Unicode支持的應(yīng)用程序可能已經(jīng)具有必要的表格和函數(shù)，因此SQLite不應(yīng)占用空間來復(fù)制此功能。

默認情況下，SQLite不提供完整的Unicode支持，而是提供了與外部Unicode比較和轉(zhuǎn)換例程鏈接的功能。應(yīng)用程序可以重載內(nèi)置的NOCASE整理序列(使用sqlite3_create_collation)和內(nèi)置的like()，upper()和lower()函數(shù)(使用sqlite3_create_function)。開發(fā)人員可以根據(jù)自己的項目中已包含Unicode識別的比較例程編寫自己的重載。

16.INSERT很慢 - 我每秒只能做幾十個INSERT。

實際上，SQLite在一臺普通臺式機上每秒鐘可以輕松完成50,000或更多的INSERT語句。但它每秒只能做幾十個事務(wù)。交易速度受到磁盤驅(qū)動器轉(zhuǎn)速的限制。一個交易通常需要磁盤盤片的兩次完整的旋轉(zhuǎn)，這在7200RPM磁盤驅(qū)動器上每秒限制您約60個事務(wù)。

交易速度受磁盤驅(qū)動器速度的限制，因為(默認情況下)SQLite實際上會一直等到數(shù)據(jù)真正安全存儲在磁盤服務(wù)上，然后交易完成。這樣，如果您突然斷電或者您的操作系統(tǒng)崩潰，您的數(shù)據(jù)仍然安全。有關(guān)詳細信息，請閱讀SQLite中的原子提交。

默認情況下，每個INSERT語句都是它自己的事務(wù)。但是，如果使用BEGIN ... COMMIT包圍多個INSERT語句，則所有插入操作都會分組到一個事務(wù)中。提交事務(wù)所需的時間將在所有隨附的插入語句中攤銷，因此每個插入語句的時間會大大減少。

另一個選項是運行PRAGMA synchronous = OFF。這個命令將導(dǎo)致SQLite不等待數(shù)據(jù)到達磁盤表面，這將使寫入操作看起來更快。但是，如果您在交易中斷電，您的數(shù)據(jù)庫文件可能會損壞。

17.我不小心刪除了我的SQLite數(shù)據(jù)庫中的一些重要信息。我怎樣才能恢復(fù)它?

如果您有數(shù)據(jù)庫文件的備份副本，請從備份中恢復(fù)信息。

如果你沒有備份，恢復(fù)是非常困難的。您可能能夠在原始數(shù)據(jù)庫文件的二進制轉(zhuǎn)儲中找到部分字符串數(shù)據(jù)。在給定特殊工具的情況下恢復(fù)數(shù)字數(shù)據(jù)也是可能的，但據(jù)我們所知，目前還沒有這樣的工具。 SQLite有時用SQLITE_SECURE_DELETE選項進行編譯，該選項用零覆蓋所有被刪除的內(nèi)容。如果是這種情況，那么恢復(fù)顯然是不可能的。自從數(shù)據(jù)被刪除以來，如果您運行了VACUUM，恢復(fù)也是不可能的。如果未使用SQLITE_SECURE_DELETE并且VACUUM尚未運行，則某些已刪除的內(nèi)容可能仍在數(shù)據(jù)庫文件中，標記為可重用的區(qū)域。但是，再次，我們知道沒有任何程序或工具可以幫助您恢復(fù)數(shù)據(jù)。

18.什么是SQLITE_CORRUPT錯誤?數(shù)據(jù)庫“畸形”意味著什么?為什么我得到這個錯誤?

當SQLite在數(shù)據(jù)庫文件的結(jié)構(gòu)，格式或其他控制元素中檢測到錯誤時，將返回SQLITE_CORRUPT錯誤。

SQLite不會損壞數(shù)據(jù)庫文件，除非是非常罕見的錯誤(請參閱DatabaseCorruption)，即使這樣，錯誤通常也很難再現(xiàn)。即使您的應(yīng)用程序在更新過程中崩潰，您的數(shù)據(jù)庫也是安全的。即使您的操作系統(tǒng)崩潰或電力損失，數(shù)據(jù)庫也是安全的。 SQLite的抗崩潰功能已經(jīng)得到了廣泛的研究和測試，并得到了數(shù)百萬用戶的多年實際經(jīng)驗的證實。“

也就是說，硬件或操作系統(tǒng)中有很多外部程序或錯誤可以破壞數(shù)據(jù)庫文件。詳細信息可以在關(guān)于SQLite以及郵件列表存檔中的原子提交和鎖定支持的討論中找到。

您可以使用PRAGM integrity_check對數(shù)據(jù)庫完整性進行徹底但時間密集的測試。

您可以使用PRAGMA quick_check對數(shù)據(jù)庫完整性進行更快速但不太完整的測試。

根據(jù)您的數(shù)據(jù)庫損壞的程度，您可以通過使用CLI將架構(gòu)和內(nèi)容轉(zhuǎn)儲到文件然后重新創(chuàng)建來恢復(fù)某些數(shù)據(jù)。不幸的是，一旦虛張聲勢從墻上掉下來，通常不可能再次將他重新聚合在一起。

19.SQLite是否支持外鍵?

從版本2.1.1開始，DISQLite3支持外鍵約束。

DISQLite3的先前版本解析了外鍵約束，但沒有強制執(zhí)行它們。等效功能可以使用SQL觸發(fā)器來實現(xiàn)。

我的WHERE子句表達式column1 =“column1”不起作用。它會導(dǎo)致返回表的每一行，而不僅僅是column1的值為“column1”的行。

在SQL中圍繞字符串文字使用單引號，而不是雙引號。這是SQL標準要求的。您的WHERE子句表達式應(yīng)為：column1 ='column2'

SQL使用包含特殊字符或關(guān)鍵字的標識符(列名或表名)的雙引號。所以雙引號是轉(zhuǎn)義標識符名稱的一種方式。因此，當你說column1 =“column1”，相當于column1 = column1，顯然總是如此。

20.SQL標準要求強制執(zhí)行UNIQUE約束，即使約束中的一個或多個列都是NULL，但SQLite不會執(zhí)行此操作。這不是一個錯誤?

也許你在引用SQL92中的以下語句：

當且僅當表中沒有兩行在唯一列中具有相同的非空值時，滿足唯一約束。

該陳述含糊不清，至少有兩種可能的解釋：

當且僅當表中沒有兩行具有相同的值并且唯一列中具有非空值時，滿足唯一約束。

當且僅當表中沒有兩行具有非空的唯一列的子集中的相同值時，才滿足唯一約束。

SQLite遵循解釋(1)，就像PostgreSQL，MySQL，Oracle和Firebird一樣。的確，Informix和Microsoft SQL Server使用解釋(2)，但是我們SQLite開發(fā)人員認為解釋(1)是對需求的最自然的解讀，我們也希望最大化與其他SQL數(shù)據(jù)庫引擎的兼容性，以及大多數(shù)其他數(shù)據(jù)庫引擎也與(1)一起使用，所以這就是SQLite所做的。

更新日志

更新sqlite3_errmsg針對某些錯誤代碼返回的錯誤消息的文本。

添加新的指針傳遞接口。

為了利用新的指針傳遞接口提供的改進的安全性，對某些擴展進行向后不兼容的更改：

擴展FTS5→需要sqlite3_bind_pointer來查找fts5_api指針。

carray(PTR，N)→需要sqlite3_bind_pointer來設(shè)置PTR參數(shù)。

記住(V，PTR)→需要sqlite3_bind_pointer來設(shè)置PTR參數(shù)。

添加了SQLITE_STMT虛擬表擴展。

添加了COMPLETION擴展 - 旨在為交互式用戶界面提供制表符完成。這是一個正在進行的工作。預(yù)計未來版本會進一步增強。

添加了UNION虛擬表擴展。

內(nèi)置日期和時間函數(shù)已得到增強，以便它們可以用于CHECK約束，表達式索引以及部分索引的WHERE子句中，前提是它們不使用'now'，'localtime'， or'utc'關(guān)鍵字。進一步的信息。

用額外的“prepFlags”參數(shù)添加了sqlite3_prepare_v3和sqlite3_prepare16_v3接口。

為sqlite3_prepare_v3提供SQLITE_PREPARE_PERSISTENT標志，并使用它來限制FTS3，F(xiàn)TS5和R-Tree擴展的后備存儲器誤用。

添加了PRAGMA secure_delete = FAST命令。當secure_delete設(shè)置為FAST時，只要不會增加I / O數(shù)量，舊內(nèi)容就會被零覆蓋。刪除的內(nèi)容可能仍會保留在免費頁面列表中，但會從所有b-tree頁面中清除。

查詢規(guī)劃器增強功能：

當為OR掃描的每個ORed項生成單獨的循環(huán)時，移動循環(huán)外的任何常量WHERE表達式，就像頂級循環(huán)所做的那樣。

查詢計劃程序檢查綁定參數(shù)的值以幫助確定部分索引是否可用。

當決定兩個估算成本相同的計劃時，將選擇偏向不使用分揀機的計劃。

最后評估涉及相關(guān)子查詢的WHERE子句約束，希望它們永遠不會被評估。

如果該子查詢從虛擬表中讀取數(shù)據(jù)，請勿對LEFT JOIN的RHS上的子查詢使用展平優(yōu)化，這樣會阻止查詢計劃程序?qū)ψ硬樵兊慕Y(jié)果創(chuàng)建自動索引，從而可能會減慢停止查詢。

為sqlite3_stmt_status接口添加SQLITE_STMTSTATUS_REPREPARE，SQLITE_STMTSTATUS_RUN和SQLITE_STMTSTATUS_MEMUSED選項。

為PRAGMA integrity_check，PRAGMA quick_check和PRAGMA foreign_key_check提供PRAGMA函數(shù)。

SQLITE_DBCONFIG_ENABLE_QPSG運行時選項啟用查詢計劃程序穩(wěn)定性保證。

其他優(yōu)化可使所用CPU周期減少2%。

Bug修復(fù)：

修復(fù)sqlite3_column_name對于使用展平優(yōu)化的查詢的行為，以便結(jié)果與其他未使用該優(yōu)化的查詢以及PostgreSQL，MySQL和SQLServer一致。

修復(fù)查詢計劃程序，以便它知道如果WHERE子句使用IS運算符，則不會在LEFT JOIN的右表上使用自動索引。

確保查詢規(guī)劃器知道，即使該列標有“NOT NULL”，展開的LEFT JOIN的任何列都可以為NULL。

在帶ATTACH附加數(shù)據(jù)庫的數(shù)據(jù)庫連接上運行時，修復(fù)了PRAGMA integrity_check中罕見的誤報。

修復(fù)如果使用某些不合理的CREATE TABLE聲明導(dǎo)致斷言錯誤的錯誤。