ADO启动连接作为一个高效的.NET程序语言。其混合了函数语言和物件导向程序编制语言，并且***的适用于编程、算法、技术和探索性开发，因此可以在使用的过程当中感受到趣味性和吸引力。
在一个客户机/服务器应用中，我们可以用好几种方法把建立和初始化数据库连接所需要的时间隐藏起来，使得应用程序既能够打开连接，又不需要用户等待应用程序启动。首先，我们可以尝试异步连接。
使用异步连接时，ADO启动连接操作之后，不等待连接完成就把控制权返回给应用程序——这样，应用程序就能够接着执行大部份初始化操作，以更快的速度完成form_load事件处理。
如果关闭并重新建立连接的时间小于连接池释放连接的时间，那么这个连接实际上是即时的。但在许多情况下（特别是用户数量不多时），让连接保持打开状态更具有现实意义。在中间层组件或ASP页面内部，如果数据库查询多次重复出现，我建议你让Connection对象保持打开状态。
另外一个改进连接性能的办法是，避免使用带有DSN的ODBC。在Microsoft，ODBC已经转入了Quick Fix Engineering（QFE，快速修理工程）状态，它意味着：除非发现重大BUG，该公司将不再在ADO启动连接或它的驱动程序上花时间。另外，考虑性能和部署问题时，ADO启动连接也是一个必须关注的问题。DSN必须安装到客户系统上，要求进行注册表查找，与OLE DB连接相比，
它建立连接所需要的时间更长——特别是当你用直接编码的方式指定ConnectionString时，这一点尤其突出。从实际效果来看，避免使用DSN降低的系统开销很有限：如果完全取消连接建立过程，对于每个连接，你也许能够剩下二到五秒时间（假设数据库连接池中已经没有连接）。然而，如果你的应用程序需要频繁地建立连接，节省的时间累计起来就很可观了。
建立数据库连接的时候，你要选择一个数据提供者。Microsoft建议我们使用ADO启动连接提供者替代默认的ODBC提供者。对比***的OLE DB本地提供者和功能类似但较早的ODBC提供者，我感到前者令人不愉快的意外之事较少。但无论是哪种情况，你都应该在决定使用某个新的提供者之前对应用进行完整地测试——代码的性能、支持的功能、行为方式都有可能发生变化。 #t#
在中间层和ASP中，在保持连接打开的情况下，我们不能（从实践来看）创建出可伸缩的组件——至少在多次调用之间是这样的。一般地，当IIS引用和释放组件、ASP页面的实例时，组件和ASP页面被频繁地装入、丢弃。由于基于ADO的代码每次执行时都必须建立、使用、释放数据库连接，最小化连接复杂程度的策略对性能的提高程度达到了可明显测量的程度。在这些情形下，
对于我们连接数据库的速度来说，ADO启动连接连接/会话池有着重要的意义。如果你为Command对象的ConnectionString属性指定合适的值（即，每次使用同样的服务器、初始目录、登录ID和其他参数），那么，连接已经打开且处于可用状态的机会很大。如果连接池中能够找到匹配的连接，连接（或重新连接）的时间将接近0（通常小于250 ms）。
然而，如果ADO（或VB）代码不释放Connection对象，或者，我们在不同的实例之间改换了ConnectionString，OLE DB必须每次建立一个新的连接。如果出现了这种情况，我们将很快耗尽连接池内可用连接的数量。要确保连接被释放，我们必须在关闭连接之后把Connection对象设置为Nothing。另外，ADO启动连接不要在Recordset Open方法中使用ConnectionString，而是以独立的方式打开Connection对象；这样，当我们要关闭Connection对象以及要把它设置成Nothing的时候，引用它就很方便了。
