Access 2010 Inside Out

Question

我最近從微軟出版社購買了這本書。我目前擁有Office Enterprise 2007（包括Access），並已決定將我的Informix-SQL應用程序轉換爲Access 2010.但是，我沒有使用VBA，宏和我的應用程序需要的其他一些功能。這對我來說將是一個新的學習過程，但我必須使我20歲的基於字符的應用現代化，並利用新的功能。我已經開始定義我的表和列，但不是關係。使用INFORMIX，我會在另一個表中加入一個INT列的序列（自動增量）列。現在，當我顯示客戶主數據行時，我想自動在子表單中顯示與該客戶相關聯的所有交易，並且可以在任一表上添加，更新，查詢和刪除。這可以用A'10來完成嗎？

編輯：好的，這是我做了什麼，到目前爲止，定義表和關係：

有更多的驗證查找表可循，但這些是主要的表。因此，如果現在我創建一個表單並指定CLIENTES（客戶表），LOTES（批次表），ARTICULOS（項目表）和TRANSACCIONES（事務表），它將創建一個CLIENT表作爲主窗體並將其他子表創建爲子窗體在一個屏幕上？

此外，我創建很多表的原因是，當客戶典當或出售物品時，當鋪將所有這些物品分組成一個批次，計算總貸款或購買金額，將其存儲在一個交易下並打印票據並說明所有項目和總金額。所以我想說的是，如果客戶違約支付利息或不贖回典當，那麼客戶將喪失所有物品，典當行可能會選擇向黃金煉油廠出售一些物品和/或將其他非黃金物品轉移到庫存以賣給公衆，那麼上述ER就足以滿足這種能力？

我也想確保每個表中的每一行都有相同的store_ID（公司ID），同時用戶在特定的公司工作，因爲這個系統將是多公司，並且會有綜合報告等。

Answer 1

這種類型的設置可以在訪問追溯到1992年。

你的模型在訪問這些經典的一對多關係的方式任何版本的完成是立足於父表中的父窗體（注意我說的partent表，而不是查詢 - 我將再次重複一遍：您不需要爲您加入數據的查詢）。然後根據子表創建所謂的繼續表單。您現在有兩種形式，然後您可以簡單地將子表格的形式拖放到上述父表單中，然後完成。實際上，如果您在關係窗口中正確設計和設置關係，那麼如果您使用嚮導來創建表單，它將實際構建並自動爲您插入一個子表單。

因此，您應該知道上面的過程有幾個有趣的問題正如我在上面指出的那樣，您根本不必構建任何SQL查詢。您不必編寫sql來將數據連接在一起。 Access將爲您完成所有這些工作，並且無需任何代碼即可完成。

因此，當您在主窗體中導航記錄時，子窗體將自動顯示並在子窗體中爲您進行過濾。 （如果您添加，刪除或編輯這些子記錄，則會爲您插入並維護正確的關係密鑰，而且完全不需要編寫任何代碼）。

在下面的表格中，我們有一個經典的會計基金分配示例。在這個例子中，我們正在跟蹤會員捐贈。因此，表單的頂部是基於主表的一條記錄，並且是捐贈活動。然後我創建了一個連續的表單。當放入主表單時，它將成爲子表單。這種形式是左側的形式，它只是讓我輸入爲上述事件捐贈的成員名單。

的形式如下：

此時表格將沒有處於被編寫任何代碼工作。

其實上面的表格我有一個主要記錄，左邊我有很多成員捐了一筆。但是，爲了會計目的，我還需要將左側的所有成員的每次捐贈分攤到特定帳戶。 （經典支票拆分，你在幾乎每一個會計套餐中看到的這些天）

所以上述模型是一對多的，然後很多成員也爲每次捐贈分成許多不同的賬戶。一個真正令人難以置信的強大的設置，並且幾乎沒有代碼。

所以，在上面我真的在做三張表作爲一個模型。 |公平地說，右側（捐贈分成賬戶）確實需要一行代碼才能正確更新，因爲當你進入3張桌子時，訪問不會爲我執行此操作。

但是，大多數情況下，要在訪問中將這些經典父對象模型化爲子對象關係，您根本不需要編寫任何代碼。您使用主窗體，然後爲子表添加基於子表的子窗體。

如上所述，如果您正確設置關係，訪問會自動將兩者縫合在一起，併爲您保持關係。因此，顯示屬於一條父記錄的子記錄將自動顯示給您。此功能包括編輯和刪除和添加這些子記錄。因此，當您導航到新的記錄時，所有子記錄和信息將自動刷新到下一個表單。

換句話說，以上所有內容都可以在不建立任何SQL查詢的情況下完成，並且不需要一行代碼。

Answer 2

不幸的是堆棧溢出很適合提出問題並有答案。然而，基於上一個問題的一個嚴重的Q + A，我們發現StackOverflow真的在這裏崩潰了。我會給出這個答案，並且對堆棧溢出的所有應有的尊重，我很高興建議你嘗試基於論壇的系統而不是如此。 Perahps奮鬥和訪問，甚至訪問開發這裏論壇：

http://social.msdn.microsoft.com/Forums/en-US/accessdev

無論如何，讓我們看看我們能想出。我還應該指出，您的表格設計以及如何關聯這些表格並不是真正的訪問問題，而只是數據庫設計的問題。對於MySql，Oracle，FoxPro或者我們業內過去20多年來的所有關係數據庫系統，這種情況應該如何佈置。所以，當您詢問如何設置數據庫時，這不是一個真正的訪問問題。

好吧，讓我們看看。在上面，您將LOTES表格附加到客戶。如果您要將LOTS表附加（關聯）給客戶，那麼您不需要LOTES表中的store_id，因爲該表是該客戶記錄的子表。任何時候你都可以到父表中去獲取這些信息，你不需要在子表中重複它。因此，您因此關聯的客戶記錄已經具有商店ID，並且您可以隨時獲得該商店ID值，因爲它是關係（這是關係數據庫的整體概念，您沒有一遍又一遍地重複數據）。

而且，正如您現在所做的那樣，對於兩個子表中的LOTES也適用相同的建議。再次，他們不需要商店ID，因爲通過上面的設計，他們已經連接到LOTES表，而LOTES表又連接到商店ID所在的顧客表。因此，在您當前的設計中，客戶下方的所有子表都可以且應該並將刪除store_id。

但是，上面我懷疑是不是你想在這裏完成。 LOTES記錄很可能屬於商店。如果是這樣的話，那麼你希望LOTES表成爲商店的孩子。

因此，你應該有商店 - > LOTES

只有一部分不清楚這裏是如果你的設計是要允許一個客戶連接到一個以上的商店。如果這是一種非常罕見的情況，那麼也許你會採用更簡單的設計，要麼迫使你再次進入顧客，要麼甚至通過一些複製代碼。雖然這裏經常會出現正常化問題，但還是會出現一些問題，例如，如果同一位客戶的送貨地址將針對不同的商店進行更改，那麼在此情況下，您通常不會通過標準化來節省大量代碼和設計問題。

但是，如果您需要此功能，則反過來也是正確的，並且正確地對這些數據進行規範化有很多優點，但通常更多的設計工作在前面。

如果您確實希望客戶擁有多個商店，那麼您需要一個名爲tblCustomerStores的表。您會將此表作爲子表附加到客戶，並且此表將具有store_id。然後，您可以將所有客戶交易等附加到此子商店表。此客戶商店表甚至可能包含付款類型和交付偏好（如果它們因店鋪不同而異）。

所以，你開始在 客戶 - >客戶商店 - >事務 - >

而且，它不是很清楚什麼是內幕交易，但它可能是別的寄託都屬於上述跨見下表。

而且，不清楚條款是否附加到特定的交易？如果是，那麼物品就成了交易的一個孩子。

我更多的

客戶 - >客戶商店 - >物品─>很多

思維和你希望客戶商店 - > Tranascation 你希望客戶商店 - >文章

所以，我認爲你目前的表格太深了。請記住，您可以將許多表格與父表格關聯起來，就像您在圖表中所示的一樣，但是我認爲它不是您要查找的內容