oRs.Open "SELECT COUNT(*) As iRowCountFROMOrders"

iCount=oRs.Fields("iRowCount").Value

ADO.NET引入了一种从查询的结果中获取单值的新方式，可以用于预计只返回一行和一列的场合。ADO.NETCommand对象有一个ExecuteScalar方法，它从相关的查询中返回第一行和第一列的值。因为不用创建行集、查找值并关闭行集，所以这样所产生的系统开销非常小。ExecuteScalar方法已经针对需要检索单值的特定场合进行了优化。下例实现的功能与前例相同，只不过使用的是ASP.NET和ADO.NET以及ExecuteScalar方法：

string sSql = "SELECTCOUNT(*) As iRowCountFROMOrders";

SqlCommandoCmd=newSqlCommand(sSql,oCn);

oCmd.CommandType = CommandType.Text;

int iCount = (int)oCmd.ExecuteScalar();

检索单值的另一种方式是使用存储过程的输出参数。例如，这一技术也可以从一个单行中检索许多值。它在ADO和ADO.NET中都适用，虽然ADO.NET已经扩展了输出参数的功能。在ADO.NET中为了从Command对象获取输出变量的值，应该使用ExecuteNonQuery方法执行查询。该方法能够通知ADO.NET，查询不会返回一个行集，因此避免了DataSet或者DataReader的系统开销：

oCmd.ExecuteNonQuery();

oCmd.UpdatedRowSource=UpdateRowSource.OutputParameters;

intiOrderID=(int)oCmd.Parameters["@OrderID"].Value;

此段代码将UpdatedRowSource属性设置为指向输出参数（假定它们已经进行了设置），然后就可以检索输出值了。在传统的ADO中这是在Connection对象的Execute方法中使用晦涩难懂的参数实现的，而我们可以看到，在ADO.NET中实现这一点已经非常简单了。当然，ADO.NET还有一个为返回标准行集进行了优化的方法—Command对象的Execute方法。在传统的ADO中，Recordset对象能够设置UPDATE、INSERT和DELETE语句，这些语句是为了使Recordset能够将对自己的任何更改应用于基础数据库所必需的。虽然这一功能非常方便，但因为必须要返回给数据库以决定如何实现，所以，它也增加了系统开销。ADO.NET对象通过CommandBuilder对象也可以实现这一点；但同样也存在着系统开销的问题。在大多数开发场景中，要求使用的确切SELECT、INSERT、UPDATE和DELETE语句在设计时是已知的。在传统的ADO中，没有什么简单的办法将操作查询与Recordset相关联从而来使用它们。而在ADO.NET中，DataAdapter有四个不同的Command对象与其相关联，可以表示每个操作查询以及SELECT语句。这使DataAdapter能够协助我们用查询的结果填充一个DataSet，还能提前通知DataAdapter对数据库发出操作查询。虽然这需要在设计时投入更多的编码工作，但是代码的增加换来的是性能上的改善（就更不用说代码易于理解所带来的维护上的轻松了）。

近几年来，ADO已经成为在基于Windows 的应用程序中执行数据访问的领先、优选的方法。今天，已经有大量的ADO应用程序付诸应用，许多开发人员已经对ADO开发非常熟练。随着Microsoft .NET Framework的引入，ADO.NET——ADO的演进版本粉墨登场了。虽然ADO和ADO.NET之间存在很多相似性，但是它们的运行方式和基础却大不相同。为了帮助读者平滑地迁移到ADO.NET，我将在本文中讲述如何用ADO.NET完成一些常见的任务。我会提出一些关于数据访问的情况进行探讨，说明如何利用ADO予以解决，并对比说明如何在用C#开发的ASP.NET应用程序通过ADO.NET进行解决。我将以连接数据源的相似操作为论述的切入点，然后，我们会看到ADO的Recordset对象在ADO.NET中如何演变为许多截然不同、各有侧重的对象和方法。最后，我将探讨流水游标(firehose cursor)，它从行集中返回一个值并使用XML。

ADO的演变

一些传统的ADO功能（例如，建立与数据源的连接）在各版本之间改变不大，而其他一些功能（例如，表示断开的行集、将行集保持为XML以及将其转换为分层次的行集）则发生了很大的变化。发生这种显著变化的原因之一在于，XML和数据构形（data-shaping）功能都是后来加入到ADO中的；而对于ADO.NET，它们在一开始就被纳入到设计中。与比较老的数据访问工具（例如DAO和RDO）相比，传统的ADO算是非常轻量级的。ADO之所以在VisualBasic 6.0 N层开发中如此流行，原因在于它简单、易于浏览的对象模型特性。ADO的Connection和Command对象可以相对容易地转换为ADO.NET的Connection和Command对象，但是ADORecordset对象的功能却要转换成ADO.NET中的许多不同的对象和方法。ADO在某种程度上依然是一种强大而流行的数据访问工具，其原因在于它的XML功能和管理断开行集的能力。ADO Recordset可以通过将其CursorLocation属性设置为adUseClient，将其CursorType属性设置为ADOpenStatic，将其LockType属性设置为adLockBatchOptimistic从而与数据源和Connection对象断开。然后，在Recordset打开并加载之后，可以通过将其ActiveConnection属性设置为Nothing，从而实现断开：

'---Disconnecting an ADO Recordset

oRs.CursorLocation=adUseClient

oRs.CursorType=ADOpenStatic

oRs.LockType = adLockBatchOptimistic '- Or use adLockReADOnly

oRS.Open

Set oRS.ActiveConnection = Nothing

XML功能并不是在一开始就集成到ADO中的，而是随着XML越来越流行，它的功能才逐步被加入到ADO较新的版本中。ADO Recordset对象的Save方法能够接收记录集的行和列，并将它们转换为预定义的XML架构，然后将其持久存留到文件或者流之中。XML架构并不是非常的灵活，但它是从ADO行集保留XML的首次真正的尝试，并且它为开发人员简要地指明了开发的方向。只要文件使用与其所期望的架构所相同的XML架构，记录集还可以从XML文件中加载。下面的代码说明了ADO如何将记录集保存到一个XML文件中：

行集可以保存到一个流中，例如来自ASP页的Response对象的输出。举例而言，一些ASP代码能够马上响应请求，检索一个行集，并将该行集流转化为Response对象，再将其返回给客户端。下面的代码说明了如何将一个记录集的内容保存到Stream对象中。此外，Save方法的第一个参数可以用Response对象代替，这样就能将XML行集流转化到调用方浏览器：

DimoStmAsADODB.Stream

SetoStm=NewADODB.Stream

oRs.Save oStm,adPersistXML

传统的ADO与ASP也能够进行流转化。当然，在.NET中也可以使用Web服务实现，而且针对于任何使用传统的ADO和ASP轻易构建的解决方案，还提供了更多的功能。事实上，Web服务是设计用来处理数据请求并将数据以XML形式通过HTTP传回的一种技术。虽然ADO可以流转化为XML，但这是后来才在设计中添加的。ADO.NET DataSet对象有WriteXml和WriteXmlSchema方法，允许将它的内容导出到一个XML文件或者是流中。因此，虽然对ADO Recordset的Save方法已经进行了重新设计，从而能够将内容导出为XML；但是ADO.NETDataSet则从一开始就具备这一功能。ADO.NET不但能够将DataSet保留为XML，而且可以从XML加载一个DataSet；此外，它还利用其类似XML的结构在其他方面展示出更多的优点。例如，因为DataSet在本质上是表示为XML的，所以它可以在物理层和逻辑层之间轻易地传递。这就是说，XML可以通过HTTP跨安全网络进行传递，这是因为它采用了基于文本的XML。由于构建于XML之上，ADO.NET可以在断开情况下工作。传统的ADORecordset根据对一些属性的设置（例如，CursorType=ADOpenStatic和CursorLocation=adUseClient）可以是连接的也可以是断开的，而ADO.NET则有专门的RowSet对象，可以连接数据源(DataReader)或者断开(DataSet)。

连接 对于创建与之连接的过程来说，传统的ADO与ADO.NET非常相似。基本上，您都要声明连接对象，将其实例化，设置它的连接字符串并打开它，请参考图1。第一个示例说明如何使用ASP和ADO打开连接，第二个示例则说明如何使用ASP.NET和ADO.NET打开连接。 图1打开一个连接

VBScript中，传统的ASP和ADO

dimoCn

dimsCn

setoCn=Server.CreateObject("ADODB.Connection")

sCn="Provider=SQLOLEDB;DataSource=(local);"&_

"InitialCatalog=Northwind;IntegratedSecurity=SSPI"

oCn.OpensCn

C#中，ASP.NET和ADO.NET

String sCn = "Provider=SQLOLEDB; DataSource=(local); Initial"+

数据库连接池技术浅析

一般情况下，在使用开发基于数据库的WEB程序时，传统的模式基本是按以下步骤：
　　 1． 在主程序（如Servlet、Beans）中建立数据库连接。
　　 2． 进行SQL操作，取出数据。
　　 3． 断开数据库连接。
　　 使用这种模式开发，存在很多问题。首先，我们要为每一次WEB请求（例如察看某一篇文章的内容）建立一次数据库连接，对于一次或几次操作来讲，或许你觉察不到系统的开销，但是，对于WEB程序来讲，即使在某一较短的时间段内，其操作请求数也远远不是一两次，而是数十上百次（想想全世界的网友都有可能在您的网页上查找资料），在这种情况下，系统开销是相当大的。事实上，在一个基于数据库的WEB系统中，建立数据库连接的操作将是系统中代价最大的操作之一。很多时候，可能您的网站速度瓶颈就在于此。
　　 其次，使用传统的模式，你必须去管理每一个连接，确保他们能被正确关闭，如果出现程序异常而导致某些连接未能关闭，将导致数据库系统中的内存泄露，最终我们将不得不重启数据库。
　　 针对以上问题，我们首先想到可以采用一个全局的Connection对象，创建后就不关闭，以后程序一直使用它，这样就不存在每次创建、关闭连接的问题了。但是，同一个连接使用次数过多，将会导致连接的不稳定，进而会导致WEB SERVER的频频重启。故而，这种方法也不可取。实际上，我们可以使用连接池技术来解决上述问题。首先，介绍一下连接池技术的基本原理。顾名思义，连接池最基本的思想就是预先建立一些连接放置于内存对象中以备使用：

　　 如图所示，当程序中需要建立数据库连接时，只须从内存中取一个来用而不用新建。同样，使用完毕后，只需放回内存即可。而连接的建立、断开都有连接池自身来管理。同时，我们还可以通过设置连接池的参数来控制连接池中的连接数、每个连接的最大使用次数等等。通过使用连接池，将大大提高程序效率，同时，我们可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。下面我们以一个名为ConnectionPool的连接池为例来看看连接池的实现。先看看ConnectionPool的基本属性：
　　 m_ConnectionPoolSize：连接池中连接数量下限
　　 m_ConnectionPoolMax：连接池中连接数量上限
　　 m_ConnectionUseCount：一个连接的最大使用次数
　　 m_ConnectionTimeout：一个连接的最长空闲时间
　　 m_MaxConnections = -1：同一时间的最大连接数
　　 m_timer：定时器
　　 这些属性定义了连接池与其中的每个连接的有效状态值。连接池的自我管理，实际上就是通过定时的对每个连接的状态、连接的数量进行判断而进行相应操作。其管理流程如下：

通过上图，我们可以定义出ConnectionPool要完成管理所需要的基本接口：
public class ConnectionPool implements TimerListener{
　　 public boolean initialize() //连接池初始化
　　 public void destroy() //连接池的销毁
　　 public synchronized java.sql.Connection getConnection() //取一个连接
　　 public synchronized void close() //关闭一个连接
　　 private synchronized void removeFromPool() //把一个连接从连接池中删除
　　 private synchronized void fillPool() //维护连接池大小
　　 public synchronized void TimerEvent() //定时器事件处理函数
}
　　 通过这几个接口，已经可以完成连接池的基本管理。在TimeEvent（）函数中完成连接池的状态检验工作，fillPool()时连接池至少保持最小连接数。因为我们要保存每一个连接的状态，所以还需要一个数据库连接对象：
class ConnectionObject{
　　 public java.sql.Connection con; public boolean inUse; //是否被使用标志
　　 public long lastAccess; //最近一次开始使用时间
　　 public int useCount; //被使用次数
}
加入了ConnectionObject对象后，在ConnectionPool中操作的应该只是ConnectionObject,而其他进程需要的只是ConnectionObject的con属性，因此我们再加入一个类，作为其他进程获得与返回连接的接口： CLASS Conn{
　　 GetConnection(); //从连接池中取出一个有效连接
　　 CloseConnection(); //返回连接，此时并没有关闭连接，只是放回了连接池
　　 DestroyPool(); //销毁连接池
}
　　 最后我们的整个系统总的架构如下：

　　 通过上面的介绍，我们可以看出，连接池技术的关键就是其自身的管理机制，以上的管理流程只是本人一点见解，关键是想向大家介绍一种思路，在此基础上，您可以进一步完善连接池技术为您所用