(6) 保存并运行页面。因为我们实际的连接还保持完好，所以现在还没有任何问题。关闭浏览器。
(7) 现在将Northwind的MDB文件从\App_Data移动至C:\Temp文件夹中，这样连接将会失败。或者，可以修改代码来尝试连接Southwind.mdb。运行页面并注意浏览器将显示一个得体的失败信息。
(8) 如果移动了Northwind.mdb，那么将其再移动回C:\BegAspNetDb\ App_ Data文件夹中。
示例说明＃4—— 处理AccessDataSource连接失败
首先，请回想一下AccessDataSource控件是SqlDataSource的派生物，并且使用了应用于OLEDB数据源的一系列异常，所以当引用了带有SQL或者OLEDB名称而不是Access名称的对象时，请不要惊讶。
请观察在页面上进行的处理连接失败的三个修改。第一，添加了GridView数据源控件的一个属性，该属性在GridView没有从数据源控件中获得任何数据时将会显示一条消息。第二，添加了数据源控件的一个属性，该属性在OnSelected事件发生时调用Data_Selected事件处理程序。请注意这处于DataSource事件中。虽然用户没有直接选择 AccessDataSource控件(也没有向用户呈现)，但是当GridView向数据源控件请求数据时，选择还是在内部发生了。第三，您编写了这段脚本。
该脚本将会接收到几个参数，其中之一就是异常。这里没有名为AccessDataSourceStatusEventArgs的对象。但是，可以获得一个内部派生出 Access- DataSource 的基本对象：SQL DataSource。SqlDataSource对象具有可以提交至AccessDataSource控件的状态参数。如果没有问题，则异常列表为空。如果有一个异常，那么代码将会进行测试来查看抛出的异常是什么类型。同样地，也没有像Access Exception一样的对象。但是，AccessDataSource将异常放入更加普通的称为OleDb Exception的对象中。假定在这个集合中的所有异常都是由连接失败造成的。我们的代码将作出反应，反馈一些友好的失败通告到名为Message的标签上。
这段代码中的最大的窍门就是始终让对象使用了三个不同的名称。使用了一个Access文件(MDB)作为数据源并使用AccessDataSource控件。但是使用了底层的SqlDataSource作为事件参数。最后，使用了普通的OLEDB异常集。很多错误都源于在所有的情况下都使用名为Access的ASP.NET 2.0对象。
您可能感兴趣的文章: