DISQLite3 Pro破解版 v5.21.0 免費(fèi)版Delphi控件

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

軟件介紹

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

軟件安裝破解教程

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

2、雙擊DISQLite3_5.21.0.exe運(yùn)行，進(jìn)入安裝向?qū)?，點(diǎn)擊next

3、點(diǎn)擊瀏覽選擇安裝路徑，點(diǎn)擊install安裝

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

軟件特色

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

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

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

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

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

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

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

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

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

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

簡(jiǎn)單易用的API。

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

SQL-92支持

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

ALTER TABLE

分析

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

開始交易

注釋

提交交易

創(chuàng)建索引

創(chuàng)建表

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

創(chuàng)建視圖

刪除

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

DROP INDEX

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

DROP觸發(fā)器

DROP VIEW

終止交易

說明

表達(dá)式

插

ON CONFLICT子句

PRAGMA

REINDEX

更換

滾動(dòng)交易

選擇

UPDATE

簡(jiǎn)單的編程接口

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

AnsiString，UnicodeString / WideString和Variant支持。

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

TDataSet支持。

TStream支持BLOB。

越來越多的Delphi示例項(xiàng)目。

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

主要特色

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

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

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

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

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

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

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

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

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

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

簡(jiǎn)單易用的API。

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

常見問題

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

簡(jiǎn)短回答：聲明INTEGER PRIMARY KEY的列將自動(dòng)增加。

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

CREATE TABLE t1(

INTEGER PRIMARY KEY，

b INTEGER);

用這個(gè)表格，聲明

INSERT INTO t1 VALUES(NULL，123);

在邏輯上相當(dāng)于說：

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

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

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

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

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

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

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

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

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

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

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

每一行都必須有一個(gè)唯一的主鍵。對(duì)于具有數(shù)字類型的列，DISQLite3認(rèn)為'0'和'0.0'是相同的值，因?yàn)樗鼈兊谋容^數(shù)值相等。 (請(qǐng)參閱上一個(gè)問題。)因此，這些值不是唯一的。

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

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

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

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

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

5.DISQLite3線程安全嗎?

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

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

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

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

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

CREATE TABLE sqlite_master (

type TEXT,

name TEXT,

tbl_name TEXT,

rootpage INTEGER,

sql TEXT);

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

SELECT name FROM sqlite_master

WHERE type='table'

ORDER BY name;

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

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

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

SELECT name FROM

(SELECT * FROM sqlite_master UNION ALL

SELECT * FROM sqlite_temp_master)

WHERE type='table'

ORDER BY name

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

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

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

DISQLite3不強(qiáng)制執(zhí)行VARCHAR的長(zhǎng)度。你可以聲明一個(gè)VARCHAR(10)，并且DISQLite3會(huì)很樂意讓你放入500個(gè)字符。它將保持所有500個(gè)字符的完整 - 它從不截?cái)唷?/p>

9.DISQLite3是否支持BLOB類型?

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

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

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

例如，假設(shè)您有一個(gè)名為“t1”的表，其中列名稱為“a”，“b”和“c”，并且您希望從此表中刪除列“c”。以下步驟說明了如何做到這一點(diǎn)：

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ù)庫(kù)文件沒有變小。這是一個(gè)錯(cuò)誤?

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

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

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

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

SQL標(biāo)準(zhǔn)指定通過在一行中放置兩個(gè)單引號(hào)來逃脫字符串中的單引號(hào)。在這方面，SQL就像Pascal編程語言一樣工作。 DISQLite3遵循這個(gè)標(biāo)準(zhǔn)。例：

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

13.什么是SQLITE_SCHEMA錯(cuò)誤，為什么我會(huì)得到一個(gè)?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19.SQLite是否支持外鍵?

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

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

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

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

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

20.SQL標(biāo)準(zhǔn)要求強(qiáng)制執(zhí)行UNIQUE約束，即使約束中的一個(gè)或多個(gè)列都是NULL，但SQLite不會(huì)執(zhí)行此操作。這不是一個(gè)錯(cuò)誤?

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

當(dāng)且僅當(dāng)表中沒有兩行在唯一列中具有相同的非空值時(shí)，滿足唯一約束。

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

當(dāng)且僅當(dāng)表中沒有兩行具有相同的值并且唯一列中具有非空值時(shí)，滿足唯一約束。

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

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

更新日志

更新sqlite3_errmsg針對(duì)某些錯(cuò)誤代碼返回的錯(cuò)誤消息的文本。

添加新的指針傳遞接口。

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

擴(kuò)展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虛擬表擴(kuò)展。

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

添加了UNION虛擬表擴(kuò)展。

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

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

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

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

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

當(dāng)為OR掃描的每個(gè)ORed項(xiàng)生成單獨(dú)的循環(huán)時(shí)，移動(dòng)循環(huán)外的任何常量WHERE表達(dá)式，就像頂級(jí)循環(huán)所做的那樣。

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

當(dāng)決定兩個(gè)估算成本相同的計(jì)劃時(shí)，將選擇偏向不使用分揀機(jī)的計(jì)劃。

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

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

為sqlite3_stmt_status接口添加SQLITE_STMTSTATUS_REPREPARE，SQLITE_STMTSTATUS_RUN和SQLITE_STMTSTATUS_MEMUSED選項(xiàng)。

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

SQLITE_DBCONFIG_ENABLE_QPSG運(yùn)行時(shí)選項(xiàng)啟用查詢計(jì)劃程序穩(wěn)定性保證。

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

Bug修復(fù)：

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

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

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

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

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