2009-11-04 20 views
0

我在Access中開發了一個全功能的數據庫。這是通過一個非常「互動」的開發者客戶端增量迭代過程完成的,因爲沒有人真正知道最終的數據庫要展示什麼。所有表格都是開發(和規範化)以及表格(和子表格),但是現在報表必須進行設計和實施。DB完成後在Access中創建報告

當然,這些形式是基於查詢,這些查詢從表單本身的條件來運行查詢並在子表單中顯示信息。現在,在實踐中,報告必須基本上是可分發的屏幕表格的可打印版本。在我的研究中,報告也基於查詢,但由於我使用的查詢是使用表單中的字段在子表單中顯示相關信息,所以我沒有看到創建這些報表,除非我基本上覆制了所有查詢不從表單中提取值。這看起來非常繁瑣而且效率低下。這是創建數據庫報告的「最佳實踐」方式嗎?

V.K.

+0

您的意思是「訪問意義上的子表單」(即以另一種形式嵌入的表單),還是僅僅意味着另一種表單的數據依賴於某些以第一種形式輸入的過濾器標識符?在第一種情況下,您不應該需要表單域引用來鏈接表單及其子表單:http://www.techonthenet.com/access/subforms/link.php – Heinzi 2009-11-04 13:36:08

+1

我認爲您的「增量迭代」的一部分應該涉及創建一個或兩個報告。報告要求應該在設計數據庫時考慮到;如果你這樣做,你就不會把自己塗在這個角落。 – JeffO 2009-11-04 14:23:05

+1

「一個非常」互動的「開發者 - 客戶端增量 - 迭代過程」是我在Access中做了大約15年的事情。超頻應用程序部署http://www.granite.ab.ca/access/ufad.htm – 2009-11-04 20:17:19

回答

2

查詢中的硬編碼表單字段在這裏是有問題的部分 - 這絕對不是「最佳實踐」。我猜你在WHERE子句中需要這些值?您可以做的是從查詢中刪除字段引用(以便查詢返回全部記錄)。在「子窗體」或「報表」中,請勿將查詢直接用作記錄源。相反,使用一些SQL來訪問您的(廣義)查詢以及其他過濾條件。例如,您的子窗體的記錄源可能是

SELECT * FROM myQuery WHERE someQueryField = Me.Parent!SomeFormField 

讓您用不同的使用相同的myQuery WHERE子句中的報告(未引用表)。

+0

如果幸運的話,並且可以使用查詢中的硬編碼表單引用來填充任何報表,那麼現在就構建這些報表(如果它們比以後更早需要它們)。對於其他報道,我會使用Heinzi的建議並修改這些查詢和表單。 – JeffO 2009-11-04 14:23:36

+0

我以爲我不應該使用SELECT *,只選擇我想要的字段,因爲當我只想要一個已知的數據子集時,將拉動記錄的所有數據效率低下。 我會嘗試並重新查詢。 – 2009-11-05 17:21:27

+0

那麼,如果myQuery已經只包含你想要的字段(這是我的印象,因爲你專門針對特定表單的需求量身定製了查詢),所以在這裏重複相同的字段列表是沒有意義的。 – Heinzi 2009-11-05 17:37:48

3

您可以在使用相同查詢啓動報表的表單上放置一個按鈕。報表查詢將使用表單中的fiels/query,然後返回相同的結果集。

+0

只有當所有信息都在一個表單上時,這纔可以工作,對嗎? 我有窗體與子窗體(和一些標籤)來顯示一組相關信息,這些信息都在不同的表中。 我會這樣做,只是打印(使用打印按鈕)報表的短表格,雖然。 – 2009-11-05 17:18:21

0

我不確定我是否瞭解您的問題,但最近與使用表單驅動報表的應用程序一起工作過,我可能會有一個提示。

您不需要想要您的報告與表單的單個記錄綁定。您想要您的報告當然使用與表單相同的recordource,當然它們顯示的是相同的數據。

其原因是,如果您將報表硬連接到表單域,則除非表單處於打開狀態,否則不能使用該報表,除非一條記錄不能顯示任何內容。

如果您創建報告以便加載所有記錄,那麼您需要能夠一次打印一條記錄,並且您只需使用DoCmd.OpenReport命令的WHERE參數,使用PK價值作爲你的標準。

所以,是的,你應該使用相同的記錄源。爲什麼會有人認爲這是一個問題?