但是，这样也带来了一些问题，比如，初学者很难理解客户/服务器的运作方式，如何分配客户和服务器的工作任务，服务器端应如何开发、客户端应如何开发，它与 Access mdb 数据库到底有何不同，等等。另外，ADP 是通过一个 SQL Server ADO 连接来进行开发和使用数据库的，那么这样一来也很难象 VB、Dephi 那样进行三层式开发，而只能进行 C/S 方式开发，使得其应用、部署没有多层式灵活。尽管是样，我个人认为 ADP 仍然是中小型企业级或部门级 SQL Server 数据库前端应用的最佳工具。

目前大多数数据库开发都是采用多层式方式，典型的是三层式，即表示层、业务逻辑层和数据存储。这样的好处在于，修改某一层时而不影响其它层，这样一来，无疑变得很灵活。而 Access ADP 是 C/S 方式，它只有两层，即由 Access ADP 实现的表示层和SQL Server 实现的数据存储层，这两层之间是通过一个 ADO 连接实现的。大家都知道 SQL Server 有自己的语言 T-SQL 来处理数据，有一定的编程能力，这样一来，数据库应用的业务逻辑的实现就只能由 Access ADP 实现的表示层和 SQL Server 实现的数据存储层来共同分担，很有可能出现任何一个地方的更改引起两层同时产生变化，这样就会造成部署的麻烦，甚至由于前端 Access ADP 的版本不同而造成冲突或系统崩溃。

因此，业务逻辑的开发直接影响数据库应用的成败。处理好业务逻辑的开发在 Access ADP 开发中就变得很重要。从实际应用可以看到，如果在 Access ADP 中实现业务逻辑，无疑会带来两个问题，一是增加网络流量，同时增加客户端和服务器端的开销；二是当变更业务逻辑时，必须同时更新所有的应用的客户端。如果在 SQL Server 中用 T-SQL 来实现业务逻辑，由于 T-SQL 语言能力有限，会带来很多开发的困难。虽然，在 SQL Server 2000 以前版本中，SQL Server 允许使用 C 语言编写扩展的存储过程来弥补 T-SQL 的不足，但这并不是我们这些初学者所需要的。

SQL Server 2005 是一个 SQL Server 划时代的版本，它依托 .NET Framewok，允许开发人员使用 .NET 下的高级语言如 VB.NET、C# 来开发 SQL Server 数据库的存储过程、函数，这样就降低开发人员开发难度，因此，我们完全可以把业务逻辑封装数据库中。

总结，建议使用 Access 2007 以上版本的 ADP 来开发 SQL Server 2005 以上版本的数据库，并将业务逻辑封装到数据库中，这样的好处，一是表示层彻底独立出来，便于部署；二是团队开发时，更方便人员分工。