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

       確實(shí)，代碼可以實(shí)現(xiàn)的功能很多，而且個(gè)性化很強(qiáng)。但是，我還想說(shuō)，這種想法是錯(cuò)誤的。

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

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

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

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

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