，要确保针对更特定异常的catch代码块在其他catch代码块之前出现，从而可由特定catch代码块首先捕获特定异常。
批量更新
ADO Recordset对象经常会用到的一种情形是进行批量更新。例如，在一个N层应用程序中，ADO Recordset可检索一个行集，将其从数据源中断开连接，并将Recordset发送到客户端层。在客户端应用程序中，对几行的更改将在断开连接的ADO Recordset中进行。然后Recordset可被发回给中间层，通过ADO Connection对象与数据库重新连接，其更改可通过UpdateBatch方法应用于数据库。UpdateBatch方法将接受Recordset中的所有被更改的行，并将更改应用于Recordset源查询中指示的源表。ADO.NET也有内置的处理批量更新的功能。DataSet是一个自成一体的、总是断开连接的行集集合，它可以存储行集中行与列的原始值和当前值。DataSet可以被发送给客户端应用程序，由后者进行更改操作。DataSet然后被发送到中间层，其更改将通过DataAdapter对象应用于数据库。图2说明了ADO.NET DataAdapter如何使用其不同的Command对象执行SELECT、INSERT、UPDATE和DELETE SQL命令：
//-- Setting the ADO.NET DataAdapter's command objects
oDa.InsertCommand = oInsCmd;
oDa.UpdateCommand = oUpdCmd;
oDa.DeleteCommand = oDelCmd;
oDa.Update(oDs.Tables["Orders"]);
ADO.NET技术在对数据库应用更新的方式上比传统的ADO批量更新技术更灵活。传统ADO是通过查看ADO Recordset的Source属性来确定保存更改的位置。例如，假定Recordset的源是：
SELECT OrderID, CustomerID, OrderDate, ShipCity, ShipCountry FROM Orders
这种情况下，在对Recordset已经进行批量更改而且调用了Recordset的UpdateBatch方法之后，Recordset必须指向发送更改的位置。它查看源的SQL语句，并确定Orders表的主键(OrderID)在语句中而且只用到了一个表。因此，它可以使用SQL语句创建UPDATE、INSERT和DELETE语句对Orders表进行处理。为了能够派生操作查询，Recordset必须知道唯一行标识符。同样，存储过程不能用于这种技术更新数据库，因为语句是隐式创建的。以下ADO 2.x代码说明了包含Orders的Recordset如何在客户端应用程序中进行更新：
'-- Using traditional ADO,
'-- Updating two rows in the client tier
oRs.Find "CustomerID = 'VINET'"
oRs.Fields("ShipCity") = "Somewhere"
oRs.Update
oRs.Find "CustomerID = 'CHOPS'"
oRs.Fields("ShipCity") = "Elsewhere"
oRs.Update
之后，一旦Recordset传回给中间层，将调用以下代码从而将已完成的更改应用于数据库：
'-- Using traditional ADO,
'-- Sending both updated rows to the database, in the business tier
oRs.UpdateBatch
ADO.NET CommandBuilder的工作方式与此类似，因为它可以自动地为DataAdapter生成UpdateCommand、InsertCommand和DeleteCommand对象。自动生成命令的过程也会带来系统开销。显式地指定要使用的INSERT、UPDATE和DELETE语句效率更高。与显式指定命令相比，使用ADO.NET CommandBuilder意味着性能更低下，在对数据源应用更改方式上的控制也更差。准确的SELECT、INSERT、UPDATE和DELETE语句通常在设计时是已知的，可以用来生成ADO.NET DataAdapter的四个不同Command属性，它们甚至可以用存储过程的名称表示。ADO.NET的这一功能是传统的ADO所缺乏的一个关键部分，这可以大大提高传统ADO的批量更新技术的灵活性。当然，这需要在设计时进行更多的编码工作，但为了获得它所提供的更大灵活性（可使您非常具体地指定SQL语句或更常见地用于为每个操作指定存储过程），付出这些努力也是值得的。
断开连接的行集
通过适当设置一些属性，ADO Recordset对象可以从其数据源中断开连接。通过断开连接，它能够在内存中存储整个行集，并在使用传统ADO的应用程序之间传递。以下代码示例将断开Recordset的连接：
'-- Disconnecting an ADO Recordset
oRs.CursorLocation = adUseClient
oRs.CursorType = adOpenStatic
oRs.LockType = adLockBatchOptimistic
oRs.Open
Set oRs.ActiveConnection = Nothing
断开Recordset的连接涉及的关键属性是CursorType和CursorLocation。CursorLocation必须设置为adUseClient，表示行集应该存储在Recordset的内存中。CursorType应该设置为adOpenStatic，这将允许行集的游标能够在任何方向上移动，但是不允许行集自动对基础数据库的更改处于敏感状态。通过结合使用这两个设置，Recordset可以断开连接，但是，全部步骤还没有完。一旦打开Recordset，因为它真的断开连接了，那么它的ActiveConnection属性应该被设置为关键字Nothing，就像上一个代码示例中看到的那样。构建ADO Recordset是为了在断开连接和已连接这两种模式下工作。但是在ADO.NET中，当DataSet完全断开连接时，DataReader要维持连接。DataSet是断开连接的ADO Recordset的继承者，因为它实现了一个客户端游标，可以向任何方向滚动，而且ADO.NET DataSet还支持许多其他功能。传统的ADO Recordset对象提供的断开连接功能非常有限，而ADO.NET DataSet对象是专门为断开连接而设计的。与Recordset
批量更新
ADO Recordset对象经常会用到的一种情形是进行批量更新。例如，在一个N层应用程序中，ADO Recordset可检索一个行集，将其从数据源中断开连接，并将Recordset发送到客户端层。在客户端应用程序中，对几行的更改将在断开连接的ADO Recordset中进行。然后Recordset可被发回给中间层，通过ADO Connection对象与数据库重新连接，其更改可通过UpdateBatch方法应用于数据库。UpdateBatch方法将接受Recordset中的所有被更改的行，并将更改应用于Recordset源查询中指示的源表。ADO.NET也有内置的处理批量更新的功能。DataSet是一个自成一体的、总是断开连接的行集集合，它可以存储行集中行与列的原始值和当前值。DataSet可以被发送给客户端应用程序，由后者进行更改操作。DataSet然后被发送到中间层，其更改将通过DataAdapter对象应用于数据库。图2说明了ADO.NET DataAdapter如何使用其不同的Command对象执行SELECT、INSERT、UPDATE和DELETE SQL命令：
//-- Setting the ADO.NET DataAdapter's command objects
oDa.InsertCommand = oInsCmd;
oDa.UpdateCommand = oUpdCmd;
oDa.DeleteCommand = oDelCmd;
oDa.Update(oDs.Tables["Orders"]);
ADO.NET技术在对数据库应用更新的方式上比传统的ADO批量更新技术更灵活。传统ADO是通过查看ADO Recordset的Source属性来确定保存更改的位置。例如，假定Recordset的源是：
SELECT OrderID, CustomerID, OrderDate, ShipCity, ShipCountry FROM Orders
这种情况下，在对Recordset已经进行批量更改而且调用了Recordset的UpdateBatch方法之后，Recordset必须指向发送更改的位置。它查看源的SQL语句，并确定Orders表的主键(OrderID)在语句中而且只用到了一个表。因此，它可以使用SQL语句创建UPDATE、INSERT和DELETE语句对Orders表进行处理。为了能够派生操作查询，Recordset必须知道唯一行标识符。同样，存储过程不能用于这种技术更新数据库，因为语句是隐式创建的。以下ADO 2.x代码说明了包含Orders的Recordset如何在客户端应用程序中进行更新：
'-- Using traditional ADO,
'-- Updating two rows in the client tier
oRs.Find "CustomerID = 'VINET'"
oRs.Fields("ShipCity") = "Somewhere"
oRs.Update
oRs.Find "CustomerID = 'CHOPS'"
oRs.Fields("ShipCity") = "Elsewhere"
oRs.Update
之后，一旦Recordset传回给中间层，将调用以下代码从而将已完成的更改应用于数据库：
'-- Using traditional ADO,
'-- Sending both updated rows to the database, in the business tier
oRs.UpdateBatch
ADO.NET CommandBuilder的工作方式与此类似，因为它可以自动地为DataAdapter生成UpdateCommand、InsertCommand和DeleteCommand对象。自动生成命令的过程也会带来系统开销。显式地指定要使用的INSERT、UPDATE和DELETE语句效率更高。与显式指定命令相比，使用ADO.NET CommandBuilder意味着性能更低下，在对数据源应用更改方式上的控制也更差。准确的SELECT、INSERT、UPDATE和DELETE语句通常在设计时是已知的，可以用来生成ADO.NET DataAdapter的四个不同Command属性，它们甚至可以用存储过程的名称表示。ADO.NET的这一功能是传统的ADO所缺乏的一个关键部分，这可以大大提高传统ADO的批量更新技术的灵活性。当然，这需要在设计时进行更多的编码工作，但为了获得它所提供的更大灵活性（可使您非常具体地指定SQL语句或更常见地用于为每个操作指定存储过程），付出这些努力也是值得的。
断开连接的行集
通过适当设置一些属性，ADO Recordset对象可以从其数据源中断开连接。通过断开连接，它能够在内存中存储整个行集，并在使用传统ADO的应用程序之间传递。以下代码示例将断开Recordset的连接：
'-- Disconnecting an ADO Recordset
oRs.CursorLocation = adUseClient
oRs.CursorType = adOpenStatic
oRs.LockType = adLockBatchOptimistic
oRs.Open
Set oRs.ActiveConnection = Nothing
断开Recordset的连接涉及的关键属性是CursorType和CursorLocation。CursorLocation必须设置为adUseClient，表示行集应该存储在Recordset的内存中。CursorType应该设置为adOpenStatic，这将允许行集的游标能够在任何方向上移动，但是不允许行集自动对基础数据库的更改处于敏感状态。通过结合使用这两个设置，Recordset可以断开连接，但是，全部步骤还没有完。一旦打开Recordset，因为它真的断开连接了，那么它的ActiveConnection属性应该被设置为关键字Nothing，就像上一个代码示例中看到的那样。构建ADO Recordset是为了在断开连接和已连接这两种模式下工作。但是在ADO.NET中，当DataSet完全断开连接时，DataReader要维持连接。DataSet是断开连接的ADO Recordset的继承者，因为它实现了一个客户端游标，可以向任何方向滚动，而且ADO.NET DataSet还支持许多其他功能。传统的ADO Recordset对象提供的断开连接功能非常有限，而ADO.NET DataSet对象是专门为断开连接而设计的。与Recordset
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
