(4) 為什么 SQLite 認為表達式 '0'=='00' 為真？

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

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

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

每一行必須有一個唯一的主鍵。作為一個數(shù)字類型的字段，SQLite 認為 '0' 和 '0.0'的值是相同的， 因為他們在數(shù)字上的比較是相等的（看前面的問題）因此值不是唯一的。

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

你需要升級你的 SQLite 庫到 2.6.3 或更新版本。

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

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

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

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

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

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

最新評論