我們知道MS Access數據庫引擎被「限制」，以允許2GB的最大文件大小（或者可能內部連線被限制爲少於2KB的4KB數據頁的某些功率）。但是這在實踐中意味着什麼？MS Access數據庫引擎表中的最大行數？
爲了幫助我衡量這一點，你能告訴我可以插入MS Access數據庫引擎表的最大行數嗎？
爲了滿足表的定義，所有的行必須是唯一的，因此需要一個唯一的約束（例如PRIMARY KEY，UNIQUE,CHECK，數據宏等）。
編輯：我意識到有一個理論上的限制，但我感興趣的是實際（並不一定切實可行），現實生活的限制。
這裏是我的嘗試：
我創建了一個單柱（INTEGER）表無鑰匙：
CREATE TABLE a (a INTEGER NOT NULL);
序列插入整數從1開始的
我停止它（任意幾個小時後）插入了65,632,875行。 文件大小爲1,029,772 KB。
我壓縮了文件，它非常輕微地減少到1,029,704 KB。
我添加了一個PK：
ALTER TABLE a ADD CONSTRAINT p PRIMARY KEY (a);
這就增加了文件大小1467708 KB。
這表明最大值約爲8000萬大關。
這一切都取決於。理論上使用4字節數據類型的單列。你可以存儲300 000行。但是即使在你做任何事情之前，數據庫中可能還有很多開銷。我讀了一些你可以擁有1.000.000行的地方，但是又一次，這取決於..
你也可以將數據庫鏈接在一起。限制你自己只有磁盤空間。
4字節記錄和300K行的數學根本不相加。我有3個表中超過300K行的長期生產數據庫（以及兩個表中的一個表），並且記錄比單個4字節字段複雜得多。數據文件的大小小於500MB（更像是一半）。 – 2009-08-03 19:07:30
是的，你是對的。我缺少一些零。 （2千兆字節）/（4字節）= 536 870 912 – Tommy 2009-08-04 07:36:46
我們不一定在這裏談論理論極限，我們正在討論2GB最大文件大小和數據庫模式的真實世界限制。
在確定您可以擁有多少行的情況下，架構與行數保持一致。
我們使用Access MDB來存儲MS-SQL數據的輸出，供我們的一些企業用戶進行統計分析。在這些情況下，我們已經導出了我們的核心表結構，通常是四個表，其中20到150列從每行100字節到每行8000字節以上不等。在這些情況下，我們會碰到數十萬行數據是我們將運送它們的PER MDB所允許的。
所以，我只是不認爲這個問題有沒有你的模式的答案。
我沒有模式。面臨的挑戰是你想出一個可以產生最多行的表的模式（提示：我正在考慮一個唯一的單列表）。 – onedaywhen 2009-08-03 15:00:00
行級鎖定也有所不同，因爲它會強制每個記錄的單個數據頁面。 – 2009-08-03 19:08:31
自從我上次使用Access以來，已經有好幾年了，但是更大的數據庫文件通常會遇到更多的問題，並且比小文件更容易發生損壞。
除非數據庫文件只被一個人訪問或存儲在一個健壯的網絡中，否則在達到2GB數據庫大小限制之前，您可能會發現這是一個問題。
正如其他人所說，它是您的架構和索引數量的組合。
一位朋友在接近2 Gb限額的MDB中擁有約100,000,000的歷史股價和每日收盤價。
他使用Microsoft知識庫文章中的一些代碼將其拉下。我很驚訝，無論他使用的服務器在第一個100K記錄後都沒有關閉他。
他可以在一秒鐘內查看任何記錄。
一些評論：
噴氣/ ACE文件是在數據頁爲單位，這意味着有是當你的記錄邊界不與您的數據頁對齊一定量的鬆弛空間。
行級鎖定將大大減少可能的記錄數，因爲它強制每個數據頁一個記錄。
在Jet 4中，數據頁大小增加到4KB（從Jet 3.x中的2KB）。由於Jet 4是第一個支持Unicode的Jet版本，這意味着您可以存儲1GB的雙字節數據（即1,000,000,000個雙字節字符），並啓用Unicode壓縮，2GB數據。所以，記錄的數量將受到您是否有Unicode壓縮的影響。
由於我們不知道一個Jet/ACE文件很大的空間是如何採取了由標題和其他元數據，也沒有精確索引存儲多少空間需要，理論計算的總是要下什麼是可行的。
爲了獲得最高效的可能存儲空間，您希望使用代碼創建數據庫而不是Access UI，因爲Access會創建純Jet不需要的某些屬性。這並不是說有很多這樣的設置，因爲設置爲Access默認值的屬性通常不會被設置（只有在您將其從默認值更改爲默認值時纔會創建該屬性 - 這可以通過循環遍歷字段屬性集合，即爲Access表設計器中的字段列出的許多屬性在屬性集合中不存在，因爲它們尚未設置），但您可能想限制自己使用Jet特定的數據類型（超鏈接字段例如，僅限訪問）。
我只是浪費了一個小時，這一點使用賽第一輪（）周圍碴來填充定義爲類型4名字節的字段，複合PK的四個領域，並花了永遠追加足夠的記錄起牀任何2GB的重要部分。在200多萬條記錄中，該文件低於80MB。我在達到
700K
7百萬記錄和文件壓縮到184MBs後終於退出。花費在2GB附近的時間只是我願意投入的時間！
實用=「有用的實踐」 - 所以你會得到最好的軼事。其他一切只是原型和測試結果。
我同意與他人 - 確定「的記錄的最大數量」完全依賴於模式 - ＃表，＃字段，索引＃。
另一個軼事爲您：我最近擊中1.6GB的文件大小與2個主數據存儲（表），36和85個字段分別與3代附加表某個子集的副本。
誰在乎，如果數據是唯一或不 - 如果context說，這是唯一的材料。數據是數據，除非重複影響索引器的處理。
總的行數構成該1.6GB的是1.72米。
當處理4個大型Db2表格時，我不僅發現了這個限制，而且讓一個老闆認爲我可以將所有四個表格（每個表格都有900,000行）附加到一個大表格上，這對我來說真的很糟糕。真正的生活結果是，無論我嘗試過多少次Table（其中有34列 - 30個文本和3個整數），都會吐出一些神祕的消息：「無法打開數據庫無法識別的格式或文件可能已損壞」。底線少於1,500,000條記錄，只有超過1,252,000條，有34行。
可以插入更新記錄的rpimary鍵值的重複行。 – 2009-08-03 09:39:58
@Ralph Rickenbach：謝謝，我沒有想到（doh！）我已經編輯了這個問題來作出一個獨特的約束條件。 – onedaywhen 2009-08-03 11:28:58
我不認爲這是正確的說Jet/ACE是「扼殺」，因爲它可能是內部連線被限制爲少於2KB的4KB數據頁的功率的一部分（我沒有得到任何不錯的圓數字嘗試了這一點，所以在那裏肯定會有一些開銷）。雖然它可能不難改變，但它不符合MS的大型產品線的利益，特別是考慮到他們真的以4GB的速度進行THROTTLE SQL Server Express - 我們知道它與完整的SQL Server是相同的引擎，但是具有人造跛行。 – 2009-08-03 19:03:36