(4) 為什么 SQLite 認(rèn)為表達(dá)式 '0'=='00' 為真？

在 2.7.0 之后，表達(dá)式不成立。參見文檔 datatypes in SQLite version 3

(5) 為什么 SQLite 不允許在同一張表里使用 '0' 和 '0.0' 作為兩個(gè)不同的行的主鍵？

你的主鍵一定是數(shù)值類型的，把類型改為 TEXT 就可以了。

每一行必須有一個(gè)唯一的主鍵。作為一個(gè)數(shù)字類型的字段，SQLite 認(rèn)為 '0' 和 '0.0'的值是相同的， 因?yàn)樗麄冊(cè)跀?shù)字上的比較是相等的（看前面的問(wèn)題）因此值不是唯一的。

(6) 為什么不能在 Linux box 中讀取在 SparcStation 中創(chuàng)建的 SQLite 數(shù)據(jù)庫(kù)？

你需要升級(jí)你的 SQLite 庫(kù)到 2.6.3 或更新版本。

x86 處理器是 little-endian 型的而 Sparc 是 big-endian 型的。新版本的 SQLite 解決了這個(gè)問(wèn)題。

注： 　　big endian和little endian是CPU處理多字節(jié)數(shù)的不同方式。例如“漢”字的Unicode編碼是 6C49。那么寫到文件里時(shí)，究竟是將6C寫在前面，還是將49寫在前面？如果將6C寫在前面，就是big endian。還是將49寫在前面，就是 little endian。

(7) 多個(gè)應(yīng)用程序或者同一個(gè)應(yīng)用程序的多個(gè)例程能同時(shí)存取同一個(gè)數(shù)據(jù)庫(kù)文件嗎？

多進(jìn)程可以同時(shí)打開同一個(gè)數(shù)據(jù)庫(kù)，也可以同時(shí) SELECT 。但只有一個(gè)進(jìn)程可以立即改數(shù)據(jù)庫(kù)。

SQLite使用讀/寫鎖定來(lái)控制數(shù)據(jù)庫(kù)訪問(wèn)。(Win95/98/ME 操作系統(tǒng)缺乏讀/寫鎖定支持，在低于 2.7.0 的版本中，這意味著在 windows 下在同一時(shí)間內(nèi)只能有一個(gè)進(jìn)程讀數(shù)據(jù)庫(kù)。在版本 2.7.0 中 這個(gè)問(wèn)題通過(guò)在 windows 接口代碼中執(zhí)行一個(gè)用戶間隔幾率讀寫鎖定策略解決了。) 但如果數(shù)據(jù)庫(kù)文件在一個(gè) NFS 文件系統(tǒng)中，控制并發(fā)讀書的鎖定機(jī)制可以會(huì)出錯(cuò)。因?yàn)?NFS 的fcntl() 文件鎖定有時(shí)會(huì)出問(wèn)題。如果有多進(jìn)程可能并發(fā)讀數(shù)據(jù)庫(kù)則因當(dāng)避免把數(shù)據(jù)庫(kù)文件放在 NFS 文件系統(tǒng)中。 根據(jù)微軟的文檔，如果不運(yùn)行 Share.exe 后臺(tái)程序則 FAT 文件系統(tǒng)中的鎖定可能不工作。對(duì) Windows 非常有經(jīng)驗(yàn)的人告訴我網(wǎng)絡(luò)文件的鎖定有許多問(wèn)題并且不可靠。如果是這樣，在2個(gè)或以上 Windows 系統(tǒng)中共享一個(gè) SQLite 數(shù)據(jù)庫(kù)文件會(huì)導(dǎo)致不可預(yù)知的問(wèn)題。

我們知道沒(méi)有其他的嵌入式 SQL數(shù)據(jù)庫(kù)引擎比SQLite支持更多的并發(fā)性。 SQLite允許多進(jìn)程 同時(shí)打開和讀取數(shù)據(jù)庫(kù)。任何一個(gè)進(jìn)程需要寫入時(shí)，整個(gè)數(shù)據(jù)庫(kù)將在這一過(guò)程中被鎖定。但這一般僅耗時(shí) 幾毫秒。其他進(jìn)程只需等待然后繼續(xù)其他事務(wù)。其他嵌入式SQL數(shù)據(jù)庫(kù)引擎往往只允許單進(jìn)程訪問(wèn)數(shù)據(jù)庫(kù)。

最新評(píng)論