2013-05-09 73 views
2

有關訪問略顯一般的問題,但希望有一個相當簡單的答案:訪問自動編號和維護唯一性在多用戶數據庫

當您在一個共享的多用戶數據庫使用自動編號,是訪問做什麼特別的事來確保它分配的號碼與其他用戶同時添加記錄的號碼是唯一的?

它是否立即聲明連接到該表的第一個用戶的下一個號碼,還是等到新的記錄將要保存並且在分配之前檢查表中所有保存的記錄的最大數量下一個號碼?

其在多用戶環境中的獨特性是否穩健?

+0

順便說一句,這是一個很好的問題(^) – 2013-05-10 00:16:07

+0

它基本上開始一個交易。如果您使用自動編號PK打開綁定到表格的表單,則會鎖定該數字。自動編號將絕對保證您的獨特性,但不會下單。如果用戶A啓動一個事務並且用戶B在同一個表上啓動一個事務,則用戶A將在數字1上鎖定,而用戶B在2上鎖定。如果用戶A沒有提交數據,用戶B將插入ID爲2的表中的第一條記錄。 – Scotch 2013-05-10 01:22:17

回答

4

爲了充分回答你的問題之間做出

  • 「訪問」(應用程序),並

  • 「訪問數據庫引擎」(又名「ACE的區別是很重要的「)及其前身Jet數據庫引擎。

當您在一個共享的多用戶數據庫使用自動編號,是獲得做什麼特別的事,以確保它分配的數量與其他用戶在同一時間加入獨特記錄什麼?

[...]

是在多用戶環境中其獨特強大的?

是。與許多其他數據庫引擎一樣,ACE通過在將記錄提交(寫入)表時正常分配該數字來確保Identity列(哪些Access稱爲「AutoNumber字段」)在多用戶環境中是唯一的。但是,ACE確實提供了Access提前獲取其AutoNumber值的機會(請參見下文)。

不[訪問]立即權利要求的下一個數字對誰已連接到該表中的第一個用戶,

號只需「連接到」一個表(例如,通過執行一個SELECT,或打開Recordset)不會影響AutoNumber字段的計數器。

或者確實[Access]等到新記錄即將被保存並且在分配下一個數字之前檢查表中所有保存記錄的最大數量?

這取決於...

如果「表」是鏈接表到ODBC數據源(例如與標識列的SQL Server表)然後是,進入「等待」,直到用戶做一些事情,將提交(保存)的新紀錄,此時它提交新記錄到數據庫服務器,然後檢索自動編號值(例如,通過SQL Server中的SELECT @@IDENTITY或其他數據庫引擎的類似機制)。但是,如果「table」是本機ACE/Jet表,那麼您可能會注意到,在開始鍵入新記錄(例如,在數據表視圖中或綁定形式)後,新的AutoNumber值立即出現, 。在這種情況下訪問(應用程序)告訴ACE(數據庫引擎),它可以要插入一個新的記錄,並請求自動編號值的時候了。 ACE返回值並遞增計數器,使得發出相同請求的另一個用戶將獲得序列中的下一個數字。請注意,此過程會「消耗」AutoNumber值:它將被用於(如果用戶保存記錄)或被丟棄(如果用戶決定不保存記錄),但不會被重新使用。這就是爲什麼

  • ACE自動編號字段是「增量」(而不是「隨機」),有時對他們有「缺口」,並

  • ,如果你開始輸入數據,命中Esc鍵到取消插入,然後再次開始輸入,AutoNumber值是不同的(因爲即使沒有保存記錄,您也「消耗」了以前的AutoNumber值。

+0

很好的解釋 - 特別是關於ACE在開始新記錄時「消耗」數字。謝謝。 – 2013-05-10 09:07:33

+0

一個很好的迴應 - 我沒有更多要補充的地方! +1 – 2013-05-11 19:38:56

+0

我使用的Informix RDB服務器在客戶端提交給服務器時指定下一個可用的SERIAL(自動編號)值。我傾向於更喜歡這種方法,因爲它不會在序列中產生任何缺陷,如果客戶端中止提交。 – 2013-09-29 08:48:17

2

答案是:是的。 MS Access數據庫與任何其他通用RDB一樣,非常適合在多用戶環境下運行(雖然在性能方面可能並不如此,但對於例如SQL Server而言,它的數據安全模型並不是那麼複雜) 。此外,在表級別提供主鍵(即自動編號)的唯一性;換句話說,它不是一個GUID(全局唯一ID)。

+0

如果Ms Access完全適合在多用戶環境中運行,爲什麼ppl更喜歡SQL來實現多用戶環境? – Santosh 2013-05-10 00:05:33

+0

取決於你有多少用戶,您的性能需求,你的資源,等等 – 2013-05-10 00:09:08

+0

其他RDB可以提供更好的性能和數據安全性,我把我的答案。 – 2013-05-10 00:11:31