在Access的學(xué)習(xí)過程中，如果你開始接觸代碼了，會發(fā)現(xiàn)這是一個神秘而又神奇的國度，在代碼的世界里，幾乎無所不能。于是很多朋友開始膜拜起來了，覺得什么都可以用代碼來實現(xiàn)。

       確實，代碼可以實現(xiàn)的功能很多，而且個性化很強。但是，我還想說，這種想法是錯誤的。

       其實，這種想法在我很多帖子里都有提到，普通情況下可以完成的不必編寫代碼。例如代碼可以創(chuàng)建表、創(chuàng)建查詢，但是難道我們不可以直觀地在相應(yīng)的界面來創(chuàng)建嗎，為什么非要抽象地這樣創(chuàng)建呢？記得一個版友提及她的某個朋友，說查詢、關(guān)系都是用代碼創(chuàng)建的，我就納悶了，這到底是在炫耀編程能力呢，還是在表明對Access不熟悉呢。我想，如果窗體也可以通過代碼來創(chuàng)建，不知道ta是不是直接在模塊（Module）里處理。

        說到這里，不得不提的一點是，還經(jīng)�？梢钥吹接腥藛枺�這句查詢語句在VBE里怎么寫？一看，這些普通語句難道就不能在設(shè)計視圖里做嗎？為什么非要把它復(fù)雜化呢？如果出于安全的考慮，不希望用戶了解這些查詢而非要使用代碼，我可以肯定地說，你錯了，至少你的出發(fā)點是錯的。因為這樣一來，后臺維護就顯得很麻煩了，如果以后需要更新一些查詢的話（例如，用戶需要多增加某些字段），估計找代碼和調(diào)試時間絕對不會少。而且，并不見得這就是安全的。Access的安全性不算太高，這已是不爭的事實了，真要破解，未必是不可能的事情。如果出于安全的考慮，可以通過設(shè)置工作組對查詢編輯運行等權(quán)限進行重分配比這個來得更實際些。

       關(guān)于查詢語句，其實還有更多可以說的。例如，在ExcelHome里就常常見到一些人不希望多做幾個查詢，然后一路嵌套，最后把本可以做三四個查詢的做成一個查詢。這估計是被SQL Sever毒害過的后遺癥吧，Access里嵌套查詢不是不可以，但過多的嵌套會降低查詢效率。特別是使用In語句，往往比左聯(lián)接或者右聯(lián)接查詢的效率降低很多。在Access里，不要什么都希望一步到位。實際上，只要結(jié)果達到了，分幾步又如何呢？正所謂“不管黑貓白貓，捉到老鼠”就是好貓，說的就是這個道理。

       我想說的是，代碼只是一項工具，把結(jié)果處理好才是目的。對代碼研究深入固然是好事，但這也只是普通功能無法實現(xiàn)，或者需要一些個性化的工作的情況下才使用的。一般來說，我是這樣建議的，正常情況能實現(xiàn)的（例如創(chuàng)建表和創(chuàng)建查詢），可以不用考慮代碼執(zhí)行，宏能實現(xiàn)的，也可以不必考慮。從代碼執(zhí)行的效率來看，宏的確比代碼慢零點幾秒，但是有這個必要嗎？在某個角度來看，宏也應(yīng)該算是代碼了吧？至少可以執(zhí)行很多命令。

       前面說了，“一步到位”是很多朋友的一個夢想，甚至成為思維慣性。例如，希望在Access里執(zhí)行Excel函數(shù)求結(jié)果。用代碼來實現(xiàn)，這當然不是不可能的事情。但是有這個必要嗎？在Excel里處理完畢再導(dǎo)入追加上去就不行嗎？的確，這看起來不方便，但是實際呢？如果有這空閑功夫去調(diào)試代碼，我在Excel里用公式很可能早就完成了，孰優(yōu)孰劣，這不用我多說了吧？