在Access的学习过程中，如果你开始接触代码了，会发现这是一个神秘而又神奇的国度，在代码的世界里，几乎无所不能。于是很多朋友开始膜拜起来了，觉得什么都可以用代码来实现。

       确实，代码可以实现的功能很多，而且个性化很强。但是，我还想说，这种想法是错误的。

       其实，这种想法在我很多帖子里都有提到，普通情况下可以完成的不必编写代码。例如代码可以创建表、创建查询，但是难道我们不可以直观地在相应的界面来创建吗，为什么非要抽象地这样创建呢？记得一个版友提及她的某个朋友，说查询、关系都是用代码创建的，我就纳闷了，这到底是在炫耀编程能力呢，还是在表明对Access不熟悉呢。我想，如果窗体也可以通过代码来创建，不知道ta是不是直接在模块（Module）里处理。

        说到这里，不得不提的一点是，还经常可以看到有人问，这句查询语句在VBE里怎么写？一看，这些普通语句难道就不能在设计视图里做吗？为什么非要把它复杂化呢？如果出于安全的考虑，不希望用户了解这些查询而非要使用代码，我可以肯定地说，你错了，至少你的出发点是错的。因为这样一来，后台维护就显得很麻烦了，如果以后需要更新一些查询的话（例如，用户需要多增加某些字段），估计找代码和调试时间绝对不会少。而且，并不见得这就是安全的。Access的安全性不算太高，这已是不争的事实了，真要破解，未必是不可能的事情。如果出于安全的考虑，可以通过设置工作组对查询编辑运行等权限进行重分配比这个来得更实际些。

       关于查询语句，其实还有更多可以说的。例如，在ExcelHome里就常常见到一些人不希望多做几个查询，然后一路嵌套，最后把本可以做三四个查询的做成一个查询。这估计是被SQL Sever毒害过的后遗症吧，Access里嵌套查询不是不可以，但过多的嵌套会降低查询效率。特别是使用In语句，往往比左联接或者右联接查询的效率降低很多。在Access里，不要什么都希望一步到位。实际上，只要结果达到了，分几步又如何呢？正所谓“不管黑猫白猫，捉到老鼠”就是好猫，说的就是这个道理。

       我想说的是，代码只是一项工具，把结果处理好才是目的。对代码研究深入固然是好事，但这也只是普通功能无法实现，或者需要一些个性化的工作的情况下才使用的。一般来说，我是这样建议的，正常情况能实现的（例如创建表和创建查询），可以不用考虑代码执行，宏能实现的，也可以不必考虑。从代码执行的效率来看，宏的确比代码慢零点几秒，但是有这个必要吗？在某个角度来看，宏也应该算是代码了吧？至少可以执行很多命令。

       前面说了，“一步到位”是很多朋友的一个梦想，甚至成为思维惯性。例如，希望在Access里执行Excel函数求结果。用代码来实现，这当然不是不可能的事情。但是有这个必要吗？在Excel里处理完毕再导入追加上去就不行吗？的确，这看起来不方便，但是实际呢？如果有这空闲功夫去调试代码，我在Excel里用公式很可能早就完成了，孰优孰劣，这不用我多说了吧？