对一个数据源进行更新的时候如何捕获并发错误的信息，这是一个很重要的问题。它对RowUpdated事件进行处理，并创建一个DataSet对象。这个对象中只包含一个表。表中列出了所出现错误的详细信息，这个DataSet对象可以返回给用户，也可以传递给决定下一步操作的进程。

因此打开页面，就可以看到从数据库中读取的行集的初始值，然后是对这个非连接数据进行修改后的内容。接下来，页面中显示了两个SQL UPDATE语句。我们直接对数据库运行这两个SQL UPDATE语句，以对其中的两行的值进行修改，而这两行同时在DataSet中也有副本。

ASP.NET应用程序包括诸如配置信息，全局应用文件，编译组件，以及其他的ASP.NET资源（页面，网络服务等）的集合。这些应用程序时以与传统的ASP同样的方式，使用IIS应用程序的根目录定义的。在默认情况下，IIS中站点的根目录是一个应用程序根目录。这是一个特定网址的根目录。例如在默认Windows2000 IIS安装中，而根目录的物理路径是c:\inetpub\wwwroot。

应用程序的根目录是ASP.NET应用程序的出发点，它包括了诸如global.asax文件以及\bin目录的资源。我们还可以使用IIS MMC管理单元在IIS中创建应用程序。另外，Visual Studio.NET和IIS中包含的命令行脚本也都可以用来创建网络应用程序。创建应用程序的方法有两种：1、创建新的站点。默认状态下，站点的根目录是一个应用程序根目录。2、把文件夹（虚拟的或物理的）标记为应用程序。这是文件夹的根目录就被定义成为应用程序的根目录。

与XML文档对象一样，一个DataSet不能针对DataSet中已经存在的任何模式或者XML的任何内联模式（即与XML数据内容在同一文档中的模式），来自动验证我们提供给ReadXml方法的XML的有效性。在DataSet中，模式通常只用来提供有关数据的预期结构的信息，而根本不用于实际验证。

当我们加载模式时，DataSet将它作为一个对表名、列名、数据类型等信息进行说明的文件。然后，当我们加载XML数据内容时，模式就可以将适当的表和列中的数据组织成新的数据行。如果遇到与模式不匹配的值或元素，则跳过该项，并将当前数据行中对应的特定列置为空。例如，打开页面时，我们会看到下拉列表中有一组源文档可供显示，然后针对所选定的文档来执行验证。

网站建设时我们往往不是以c:\Wrox这种形式创建Wrox目录，并且把它标记为虚拟目录的，而是可能已经创建了目录c:\inetpub\wwwroot\Wrox。Wrox并把它作为default web size的物理目录。由于c:\inetpub\wwwroot\Wrox是物理目录，我们必须手动地把它标记为应用程序，以便把它用作ASP.NET应用程序的根目录。

我们可以通过正确地单击IIS中任何虚拟或物理的文件夹，并选择properties来做到这一点。这样将会出现那个文件夹的属性对话框，例如我们的\Wrox文件夹。在对话框中我们可以看到对当前文件夹，local path值以及文件夹允许的许可等进行设置。在这种情况下，默认许可read，log visits以及index this resource are set。

在.NET中，装配件用来描述组件，它是打包了的可复用的，编译了的代码单元，是使用.NET建立的。和ASP不同，ASP.NET不要求本地服务器有访问注册组件的权限。而只需要把我们的装配件使用FTP，DAV等方法拷贝到ASP.NET\bin目录下。接着\bin目录中的装配件就会通过ASP.NET自动装载，而这时应用程序就可以使用组件了。

1、不需要本地服务器访问权限。在ASP.NET中部署组件式很简单的。我们并不需要本地服务器访问权限，我们只需要把编译的装配件拷贝到\bin目录。做到这一步，ASP.NET会完成其他的部分了。COM组件的位置和内部结构都需要明确地记录在注册表中，而现在情况不同了，.NET装配件是自我说明的。也就是，装配件的内容包括元数据，它正确地描述了编译组件可以做什么，不能做什么。这样，成功地使用这样的组件所需要的信息都在一个位置，不需要额外的配置。

ASP组件一般来说是以DLL为后缀的文件存在的。它允许使用者根据不同需要,来调用系统COM组件，以完成所要达到目的。常用的有：上传组件、email组件、统计组件、文件管理组件等。通常ASP组件可以通过VB6来进行开发和编译。当然C或C++开发的也同样可以在ASP中使用或在客户端脚本javascript中使用，但在.NET平台无法使用。

在ASP中，如果我们想替换一个组件，那么就需要先停止IIS，然后再次运行它，原因是组件是在IIS进程中加载的。由于ASP.NET从不给文件加锁，因而我们删除或者修改应用程序的时候只需要简单地删除或复制装配件，而这一过程也不需要访问本地服务器的。

高速缓存为管理数据添加了许多强大的新功能，而这些数据我们通常把其初始存储在Application状态中，依赖性则允许我们使用项建立各种关系，而这些项可以使Cache无效，同时还允许我们建立回调，这些回调使我们可以无论何时项被从Cache中删除都执行我们的代码。

ASP.NET中的状态管理对于用过ASP的开发人员来说应该是非常熟悉的。其中Session和Application状态在使用方法上和ASP中是完全相同的，现在我们又多了一种新的选择Cache的使用。怎样理解状态管理以及在什么时候使用各个选择是非常重要的。

传统的ASP中的Session对象在ASP.NET中得到了更新和提高。在传统ASP中使用Session出现的主要问题是：

一、web farm挑战，Session数据存储在创建它的服务器的内存中。在web farm情况下，通常会有多个web服务器，如果用户想重新定向到一个不是存储其Session状态的服务器上，那么就会出现问题。通常情况下，这种问题可以用一个IP路由解决方案（此方案中客户端的IP地址用来把客户端路由到特定的服务器上）；来进行管理。不过，由于一些ISP使用反向代理的组，所以客户端的请求可能来自每个请求的不同的IP。如果用户重新定向到一个不是包含其Session数据的服务器，那么本身设计有问题的应用程序就会被破坏。

状态管理是在web应用程序的生存期内或用户和应用程序进行交互的过程中目标或值的持续。下面简单介绍一下为应用程序提供的两种管理状态的方法：

一、用户状态（回话），用户状态是通过Session对象来进行控制的。Session可以使我们在一定的时间内（默认值为20分钟）为特定的用户保留数据。以及禁止其他用户使用数据。例如，如果我们想要跟踪已为特定用户显示的广告标题，就可以使用Session状态。如果用户没有能够在可配置的Session时间范围内和站点联系，那么数据就会过期并且被删除。

ASP.NET中的Session有了哪些新功能
一、ASP.NET Session现在既可以支持存储使用windows Service的进程中的Session数据（在ASP.NET使用的相同的内存中）和进程外的Session数据（不在ASP.NET使用的内存中）。也可以存储SQL Server(持久存储)中的Session数据。Windows Service和SQL Server解决方案都支持web组，此时所有的web服务器可以配置为共享公用的Session存储。因此当用户路由到不同的服务器上时，每个服务器都可以访问该用户的Session数据。对于使用Session的开发人员来说，这是很浅显易懂的，同时它不需要对应用程序中的代码进行任何修改——不过我们必须对ASP.NET进行配置，以使它支持其中的一种进程外选项。