2-9 察看与修改DTS包属性
Microsoft? SQL Server? 2000的数据转换服务允许您透过「DTS设计器」的图形化操作接口或是以程控方式来察看或修改DTS包属性。不过本节的重点，将着重如何使用「DTS设计器」来完成DTS包属性的察看与修改作业。
欲使用「DTS设计器」来察看与修改DTS包属性，请将DTS包开启于「DTS设计器」中，然后如图表2-37所示，使用鼠标右键点击设计空间的空白区域，并从快捷菜单中选取「包属性」指令，接下来，您可以在「DTS包属性」对话框的各个页面中，察看或修改DTS包的各类属性。
图表2-37
在以下的各个段落中，我们就将DTS包属性分门别类，并说明它们的用途以及如何于「DTS包属性」对话框中察看与修改。
包识别信息
于图表2-38所示的「常规」页面中会显示出DTS包的各项识别信息，包括：名称、描述、包与版本的GUID、建立者、建立日期…等等。我们可以发现，其中大多数的属性都是只读的，允许您修改的属性只有描述、执行参数的优先级类别与同时间执行任务的最大数量是多少。
图表2-38
执行与错误信息
您可以切换至图表2-39所示的「日志记录」页面，以便设置是否要将DTS包的执行信息与错误记录下来，并决定是否一发生错误就要停止执行。此外，您还可以设置一旦用来记录DTS包执行信息的记录文件（Log File）发生错误时就停止执行DTS包。
图表2-39
如何记录执行信息
「记录」页面上半部的「记录」区域用来决定要如何记录DTS包的执行信息。
如果您勾选复选框 □将包执行日志记录到 SQL Server，包与步骤的执行信息将会储存至您利用「服务器」下拉列表所指定之SQL Server的msdb数据库中，包的相关信息会存放至sysdtspackagelog表，包中每一个步骤的信息则会存放至sysdtssteplog表。
那些并未执行步骤的相关信息并不会被储存起来。
Microsoft? SQL Server? 2000的数据转换服务允许您透过「DTS设计器」的图形化操作接口或是以程控方式来察看或修改DTS包属性。不过本节的重点，将着重如何使用「DTS设计器」来完成DTS包属性的察看与修改作业。
欲使用「DTS设计器」来察看与修改DTS包属性，请将DTS包开启于「DTS设计器」中，然后如图表2-37所示，使用鼠标右键点击设计空间的空白区域，并从快捷菜单中选取「包属性」指令，接下来，您可以在「DTS包属性」对话框的各个页面中，察看或修改DTS包的各类属性。
图表2-37
在以下的各个段落中，我们就将DTS包属性分门别类，并说明它们的用途以及如何于「DTS包属性」对话框中察看与修改。
包识别信息
于图表2-38所示的「常规」页面中会显示出DTS包的各项识别信息，包括：名称、描述、包与版本的GUID、建立者、建立日期…等等。我们可以发现，其中大多数的属性都是只读的，允许您修改的属性只有描述、执行参数的优先级类别与同时间执行任务的最大数量是多少。
图表2-38
执行与错误信息
您可以切换至图表2-39所示的「日志记录」页面，以便设置是否要将DTS包的执行信息与错误记录下来，并决定是否一发生错误就要停止执行。此外，您还可以设置一旦用来记录DTS包执行信息的记录文件（Log File）发生错误时就停止执行DTS包。
图表2-39
如何记录执行信息
「记录」页面上半部的「记录」区域用来决定要如何记录DTS包的执行信息。
如果您勾选复选框 □将包执行日志记录到 SQL Server，包与步骤的执行信息将会储存至您利用「服务器」下拉列表所指定之SQL Server的msdb数据库中，包的相关信息会存放至sysdtspackagelog表，包中每一个步骤的信息则会存放至sysdtssteplog表。
那些并未执行步骤的相关信息并不会被储存起来。
如果您希望在将执行信息写入Log的过程中若Log本身出现错误，则停止执行DTS包的话，请勾选复选框 □出现日志错误时使包失败。一般而言，Log本身之所以会发生错误，最常见的原因不外乎是事件记录缓冲区太小或是用以记录执行信息的服务器记录表的名称被更改。
如果您想要将sysdtspackagelog与sysdtssteplog表中有关DTS包与其各个步骤之执行信息的记录删除，请按下「删除记录」按钮。
如何记录错误信息
「记录」页面下半部的「错误处理」区域用来决定要如何记录DTS包的错误信息。
欲将DTS包执行时的错误信息记录下来，首先必须于「错误文件」文本输入框中指定错误文件的名称（必须包含完整的磁盘目录路径），由于错误文件是一个文本文件，因此请以 .TXT作为扩展名。如果您所指定的错误文件于DTS包执行时并不存在，它将会自动被建立。错误文件除了会列出各个已执行的步骤与它们的执行结果外，亦会列出所有未被执行的步骤。
如果您希望当DTS包发生第一个错误后就立即停止执行，请勾选复选框 □第一次出错时使包失败；如果您并未勾选此复选框，不论发生多少个错误，DTS包都会持续执行，并且在执行完毕时产生成功的状态信息。
包全局变量
切换至「全局变量」页面，即可替DTS包建立、修改、删除全局变量，全局变量的用途与维护方式另有专节说明，于此不再浪费篇幅赘述。
数据沿袭（Data Lineage）
如果您的DTS包系储存至Meta Data Services，则可以如图表2-40所示，使用「高级」页面之「历程」区域中的选项用来设置数据沿袭属性。如果您将DTS包储存至Meta Data Services，将可透过数据转换服务的数据沿袭功能，判断出任何一部分数据的来源以及套用至该数据的转换。
勾选复选框 □将沿袭变量显示为源列 表示要新建全局数据沿袭变量至此包，但是不将它们写入Meta Data Services中。一般来说，当您需要建立自定义任务以便写入历程追踪与审核信息，可以勾选此复选框。说得更明白些，勾选复选框 □将沿袭变量显示为源列 表示告知数据转换服务您要启用数据审核功能，此意味着，您希望将进出此DTS包之数据的相关信息储存起来，以便据此判断出哪些数据被DTS包导入或修改。
勾选复选框 □将沿袭变量显示为源列 之后，接下来的任务便是决定如何去储存数据沿袭变量中的审核信息，此处唯一的选择，是去勾选复选框 □将沿袭变量写入知识库 以便将审核信息写入储存机制（Repository）中。
如果您想要将sysdtspackagelog与sysdtssteplog表中有关DTS包与其各个步骤之执行信息的记录删除，请按下「删除记录」按钮。
如何记录错误信息
「记录」页面下半部的「错误处理」区域用来决定要如何记录DTS包的错误信息。
欲将DTS包执行时的错误信息记录下来，首先必须于「错误文件」文本输入框中指定错误文件的名称（必须包含完整的磁盘目录路径），由于错误文件是一个文本文件，因此请以 .TXT作为扩展名。如果您所指定的错误文件于DTS包执行时并不存在，它将会自动被建立。错误文件除了会列出各个已执行的步骤与它们的执行结果外，亦会列出所有未被执行的步骤。
如果您希望当DTS包发生第一个错误后就立即停止执行，请勾选复选框 □第一次出错时使包失败；如果您并未勾选此复选框，不论发生多少个错误，DTS包都会持续执行，并且在执行完毕时产生成功的状态信息。
包全局变量
切换至「全局变量」页面，即可替DTS包建立、修改、删除全局变量，全局变量的用途与维护方式另有专节说明，于此不再浪费篇幅赘述。
数据沿袭（Data Lineage）
如果您的DTS包系储存至Meta Data Services，则可以如图表2-40所示，使用「高级」页面之「历程」区域中的选项用来设置数据沿袭属性。如果您将DTS包储存至Meta Data Services，将可透过数据转换服务的数据沿袭功能，判断出任何一部分数据的来源以及套用至该数据的转换。
勾选复选框 □将沿袭变量显示为源列 表示要新建全局数据沿袭变量至此包，但是不将它们写入Meta Data Services中。一般来说，当您需要建立自定义任务以便写入历程追踪与审核信息，可以勾选此复选框。说得更明白些，勾选复选框 □将沿袭变量显示为源列 表示告知数据转换服务您要启用数据审核功能，此意味着，您希望将进出此DTS包之数据的相关信息储存起来，以便据此判断出哪些数据被DTS包导入或修改。
勾选复选框 □将沿袭变量显示为源列 之后，接下来的任务便是决定如何去储存数据沿袭变量中的审核信息，此处唯一的选择，是去勾选复选框 □将沿袭变量写入知识库 以便将审核信息写入储存机制（Repository）中。
您可别被「储存机制」（Repository）这个名词给吓坏了，储存机制其实就是存放数据的地方，在大多数人的眼中，储存机制就是一个数据库，事实上任何可以存放数据的地方都可以被视为是储存机制。因此，储存机制可以是SQL Server数据库、Access数据库、文本文件、XML文件…等等。
然而，在您勾选复选框 □将沿袭变量显示为源列之前，请仔细想想是否真的需要去审核数据并记录下哪些数据被修改。毕竟此举会降低DTS包的执行速度，它甚至会因DTS包本身所处理的数据就非常庞大而造成系统严重的负荷。基于此原因，我们通常只有在测试系统时才会去勾选复选框 □将沿袭变量显示为源列，抑或是当DTS包在实际运行时发生问题而想要去追踪相关数据被做了哪些修改，另外一种状况则是自一个您无权掌控的外部数据来源导入数据，但是却在导入时发生一些问题而需要去追踪导入的数据。
图表2-40
Meta Data Services扫描
透过Meta Data Services扫描选项，您可以替SQL Server以外的数据来源产生「数据库目录」（Catalog）信息。比方说，您想要将一个Microsoft Visual FoxPro数据库中的数据导入SQL Server中，欲达此目的，您可以在Meta Data Services中建立一个DTS包，并使用OLE DB作为所要导入数据的数据来源，此包会去扫描将被导入的数据并将必要的数据库目录信息（包括：表、字段、中继数据…等等）置入DTS Meta Data Services信息模型中。
1. 所谓的「数据库目录」（Catalog）其实指的就是「数据结构」（Data Structure），包括SQL Server、Oracle、Informix、Access、Visual FoxPro…等在内的任何数据库都拥有一个数据结构。在此之所以要称之为数据库目录，主因是数据转换服务实际上是透过OLE DB的catalog函数调用来取得相关信息。
2. 此处的中继数据（Meta Data）指下列信息：
- 主索引键与外部索引键。
- 字段型态、大小、精确度、小数点位数与是否允许Null值。
- 索引。
2. 此处的中继数据（Meta Data）指下列信息：
- 主索引键与外部索引键。
- 字段型态、大小、精确度、小数点位数与是否允许Null值。
- 索引。
Microsoft? SQL Server? 2000 Meta Data Services的OLE DB扫描程序会去扫描所要导入的数据，并使用OLE DB的内建功能去分析结构描述（Schema）。扫描程序会使用数据库信息模型（DBM：Database Information Model）与DTS Meta Data Services信息模型，在Meta Data Services中建立一组对应的默认实例对象。
图表2-41
欲使用扫描选项，请切换至「高级」页面，并按下「扫描选项」区域中的「选项」按钮来开启图表2-41所示的「扫描选项」对话框，此对话框中的选项能够让我们进行下列设置：（注：DTS包必须储存至Meta Data Services才能使用扫描选项）
要求DTS包要使用既存的数据库目录，或是固定去彻底扫描数据来源并返回其数据库目录的一个新默认实例。
采用所有的字段或是仅采用相关联的字段。
藉由将整个数据库目录返回，自数据库目录上一次被建立之后在任何结构或数据上的异动都可以取得。以下我们就来说明如何使用「扫描选项」对话框中的选项，首先，您必须勾选复选框 □将包引用解析到所扫描的目录元数据，以便将包连结至Meta Data Services中继数据，然后才能够使用下列两组选项：
应扫描哪些目录？
如果 知识库中存在已扫描的目录，则使用这些目录
如果先前已经扫描过数据库目录并储存下来，而且该数据库目录自前一次扫描后没有异动过，请选取此选项钮，以便沿用前一次所扫描的数据库目录。此举的好处是，不需要再次扫描与储存，因此DTS包能够执行得较快速。但是请注意，如果数据库目录有任何异动，而且您仍然选取此选项钮，将造成DTS包所参考的Meta Data Services中继数据是无意义的。
将所有引用的目录扫描到知识库中
如果选取此选项钮，则每当DTS包被执行时，便会将所有的数据库目录信息（包括：所有的表、字段与中继数据信息）扫描至Meta Data Services中，并且会去更新Meta Data Services信息模型。显而易见地，此举虽然会耗费较多的时间与资源并降低执行效率，但是却是较妥善的做法。
选择扫描选项
如果知识库中没有目录，则扫描目录
如果选取此选项钮，则当Meta Data Services中不存在任何数据库目录时，便会加入数据来源的数据库目录。一般来说，当一个DTS包仍处于开发期间，抑或是DTS包每次被执行时便会寻找一个新的数据来源时，便会选取此选项钮。比方说，假设DTS每天都会接受一个以日期作为文件名称的文件，此时就应该选取此选项钮。
总是扫描目录
如果选取此选项钮，则不论Meta Data Services中是否已存在数据库目录，都会固定将数据来源的数据库目录扫描至Meta Data Services中。时间成本将是选取此选项钮的最大考虑，因此，只有当数据来源的数据库目录异动频率很高时，才选取此选项钮。
至此可以了解，透过上述的扫描选项，将能确保数据库目录信息（亦即数据来源的结构描述）是最新的。当然，您也必须考虑到各个选项对DTS包之执行效率的影响，因此，请根据自身的需求做出适切的设置吧！
事务（Transaction）
所谓的「事务」（Transaction）即是将多项数据库更新作业组合成单一个任务单元，此任务单元中的各项数据库更新作业要就全部被认可（Commit）、否则就全部被复原（RollBack），事务使我们能达到不可部分完成、一致性、隔离与持续等特性。至于更一步的「分布式事务」（Distributed Transaction）则是允许您将多个平台上的各项操作并入单一事务中。
数据转换服务允许您于DTS包中使用事务，然而由于DTS包中的各项作业往往会涉及多个平台，因此其事务将是一种分布式事务，由于Microsoft? SQL Server? 2000的分布式事务系透过「分布式事务协调员」（MS DTC：Microsoft Distributed Transaction Coordinator）来支持，因此欲使DTS包事务能够运行，执行DTS包的计算机必须启动「分布式事务协调员」。
您可以使用下列两种方式来启动「分布式事务协调员」：
如图表2-42所示，使用「SQL Server服务管理器」来启动「分布式事务协调员」。
图表2-42
如图表2-43所示，于SQL Server Enterprise Manager中启动「分布式事务协调员」。
图表2-43
至此我们了解，DTS包亦可是构成事务之各项数据库作业的一份子，如果某一个事务是由多个DTS包所组成，则每一个DTS包与其中的每一步骤都必须执行成功，则该事务才会被视为成功并加以认可，「认可」（Commit）会去实际储存事务中所做的任何异动；只要事务中的任何一个部分失败，则整个事务就被视为失败，当一个事务失败时，系统会恢复至事务开始前的状态，而此一恢复事务中所作之任何更新的程序称之为「复原」（RollBack）。
加入包事务
一个包事务并不会存在，直到包内的某一个步骤尝试加入事务才会替此包建立一个新的事务。如果在第一个事务已认可或复原之前，其它步骤尝试去加入此包事务，这些步骤将会被加入第一个事务中。虽然一个包可以启动好几个事务，但是同一时间只能有一个事务处于作用状态中。
如果一个步骤加入包事务，该步骤所做的任何异动将累积在包事务中；如果一个步骤并未加入包事务，该步骤所做的任何异动会立即认可。一个步骤要能够加入包事务，必须满足下列条件：
必须是支持的任务类型之一
某些任务所执行的操作是不能加入包事务中的。举例来说，文件传输协议任务会直接将文件写入磁盘，此动作根本不可能复原，所以文件传输协议任务不能加入包事务中。
以下所列的各个任务不能加入包事务中：
「文件传输协议任务」
「动态属性任务」
「发送邮件任务」
「复制SQL Server对象任务」
某些任务允许用户去建立它们自己的Script或程序并自DTS中来执行。虽然这些任务能够建立并独自管理它们自己的本机或分布式事务，它们仍然不能访问DTS包事务。这些任务包括：
「ActiveX Script任务」
「执行进程任务」
就以下所列的各个任务而言，如果使用了支持的连接，将可以加入包事务中：
「大量插入任务」
「数据驱动的查询任务」
「转换数据任务」
「执行包任务」
「执行SQL任务」
「消息队列任务」
DTS连接的数据来源必须支持分布式事
图表2-41
欲使用扫描选项，请切换至「高级」页面，并按下「扫描选项」区域中的「选项」按钮来开启图表2-41所示的「扫描选项」对话框，此对话框中的选项能够让我们进行下列设置：（注：DTS包必须储存至Meta Data Services才能使用扫描选项）
要求DTS包要使用既存的数据库目录，或是固定去彻底扫描数据来源并返回其数据库目录的一个新默认实例。
采用所有的字段或是仅采用相关联的字段。
藉由将整个数据库目录返回，自数据库目录上一次被建立之后在任何结构或数据上的异动都可以取得。以下我们就来说明如何使用「扫描选项」对话框中的选项，首先，您必须勾选复选框 □将包引用解析到所扫描的目录元数据，以便将包连结至Meta Data Services中继数据，然后才能够使用下列两组选项：
应扫描哪些目录？
如果 知识库中存在已扫描的目录，则使用这些目录
如果先前已经扫描过数据库目录并储存下来，而且该数据库目录自前一次扫描后没有异动过，请选取此选项钮，以便沿用前一次所扫描的数据库目录。此举的好处是，不需要再次扫描与储存，因此DTS包能够执行得较快速。但是请注意，如果数据库目录有任何异动，而且您仍然选取此选项钮，将造成DTS包所参考的Meta Data Services中继数据是无意义的。
将所有引用的目录扫描到知识库中
如果选取此选项钮，则每当DTS包被执行时，便会将所有的数据库目录信息（包括：所有的表、字段与中继数据信息）扫描至Meta Data Services中，并且会去更新Meta Data Services信息模型。显而易见地，此举虽然会耗费较多的时间与资源并降低执行效率，但是却是较妥善的做法。
选择扫描选项
如果知识库中没有目录，则扫描目录
如果选取此选项钮，则当Meta Data Services中不存在任何数据库目录时，便会加入数据来源的数据库目录。一般来说，当一个DTS包仍处于开发期间，抑或是DTS包每次被执行时便会寻找一个新的数据来源时，便会选取此选项钮。比方说，假设DTS每天都会接受一个以日期作为文件名称的文件，此时就应该选取此选项钮。
总是扫描目录
如果选取此选项钮，则不论Meta Data Services中是否已存在数据库目录，都会固定将数据来源的数据库目录扫描至Meta Data Services中。时间成本将是选取此选项钮的最大考虑，因此，只有当数据来源的数据库目录异动频率很高时，才选取此选项钮。
至此可以了解，透过上述的扫描选项，将能确保数据库目录信息（亦即数据来源的结构描述）是最新的。当然，您也必须考虑到各个选项对DTS包之执行效率的影响，因此，请根据自身的需求做出适切的设置吧！
事务（Transaction）
所谓的「事务」（Transaction）即是将多项数据库更新作业组合成单一个任务单元，此任务单元中的各项数据库更新作业要就全部被认可（Commit）、否则就全部被复原（RollBack），事务使我们能达到不可部分完成、一致性、隔离与持续等特性。至于更一步的「分布式事务」（Distributed Transaction）则是允许您将多个平台上的各项操作并入单一事务中。
数据转换服务允许您于DTS包中使用事务，然而由于DTS包中的各项作业往往会涉及多个平台，因此其事务将是一种分布式事务，由于Microsoft? SQL Server? 2000的分布式事务系透过「分布式事务协调员」（MS DTC：Microsoft Distributed Transaction Coordinator）来支持，因此欲使DTS包事务能够运行，执行DTS包的计算机必须启动「分布式事务协调员」。
您可以使用下列两种方式来启动「分布式事务协调员」：
如图表2-42所示，使用「SQL Server服务管理器」来启动「分布式事务协调员」。
图表2-42
如图表2-43所示，于SQL Server Enterprise Manager中启动「分布式事务协调员」。
图表2-43
至此我们了解，DTS包亦可是构成事务之各项数据库作业的一份子，如果某一个事务是由多个DTS包所组成，则每一个DTS包与其中的每一步骤都必须执行成功，则该事务才会被视为成功并加以认可，「认可」（Commit）会去实际储存事务中所做的任何异动；只要事务中的任何一个部分失败，则整个事务就被视为失败，当一个事务失败时，系统会恢复至事务开始前的状态，而此一恢复事务中所作之任何更新的程序称之为「复原」（RollBack）。
加入包事务
一个包事务并不会存在，直到包内的某一个步骤尝试加入事务才会替此包建立一个新的事务。如果在第一个事务已认可或复原之前，其它步骤尝试去加入此包事务，这些步骤将会被加入第一个事务中。虽然一个包可以启动好几个事务，但是同一时间只能有一个事务处于作用状态中。
如果一个步骤加入包事务，该步骤所做的任何异动将累积在包事务中；如果一个步骤并未加入包事务，该步骤所做的任何异动会立即认可。一个步骤要能够加入包事务，必须满足下列条件：
必须是支持的任务类型之一
某些任务所执行的操作是不能加入包事务中的。举例来说，文件传输协议任务会直接将文件写入磁盘，此动作根本不可能复原，所以文件传输协议任务不能加入包事务中。
以下所列的各个任务不能加入包事务中：
「文件传输协议任务」
「动态属性任务」
「发送邮件任务」
「复制SQL Server对象任务」
某些任务允许用户去建立它们自己的Script或程序并自DTS中来执行。虽然这些任务能够建立并独自管理它们自己的本机或分布式事务，它们仍然不能访问DTS包事务。这些任务包括：
「ActiveX Script任务」
「执行进程任务」
就以下所列的各个任务而言，如果使用了支持的连接，将可以加入包事务中：
「大量插入任务」
「数据驱动的查询任务」
「转换数据任务」
「执行包任务」
「执行SQL任务」
「消息队列任务」
DTS连接的数据来源必须支持分布式事
一个步骤要能够加入包事务，其DTS连接的数据来源必须支持分布式事务。比方说，如果一个步骤的DTS连接系连接至Microsoft? SQL Server，它就可以加入包事务；如果一个步骤的DTS连接系连接至Microsoft? Access 2000，它将不能加入包事务。尝试将一个使用不被支持之DTS连接的步骤加入包事务，于执行时期将会发生错误。
以下所列的数据来源支持分布式事务
Microsoft OLE DB Provider for SQL Server
ODBC数据来源
ODBC驱动程序必须支持连接属性SQL_ATT_ENLIST_IN_DTS而且此属性务必加以设置。
Microsoft Data Link
Microsoft Data Link系被用来访问任何已安装的OLE DB Provider。一个OLE DB Provider要想加入分布式事务中，它必须采用ITransactionJoin接口。
一般来说，于DTS包中使用事务的整个设置流程如下所示：
1. 启用事务
要能够在DTS包中使用事务的第一件事，就是必须如图表2-44所示，于「DTS包属性」对话框的「高级」页面中，勾选复选框 □ 使用事务，此举表示允许在DTS包中定义及使用任务的事务单元；如果您并未勾选此复选框，将没有任何的包事务会被建立，而且步骤要求加入事务的请求亦会被忽略。
图表2-44
2. 将某一个步骤加入包事务
欲将某一个步骤加入包事务，请开启该步骤的「工作流属性」对话框并切换至「选项」页面，然后勾选复选框 □有事务时联接（如图表2-45所示）。此举会将此步骤加入包事务，而且更新将会一直累积直到认可或复原为止。
当一个步骤加入包事务，此步骤所使用的每一个DTS连接也都会加入分布式事务中。这种DTS连接的所有更新将会累积在包事务中，即使它们起源于一个并未加入包事务的步骤。因此，欲于一个包中针对同一个数据库执行事务与非事务的更新，必须使用两个DTS连接。
以下所列的数据来源支持分布式事务
Microsoft OLE DB Provider for SQL Server
ODBC数据来源
ODBC驱动程序必须支持连接属性SQL_ATT_ENLIST_IN_DTS而且此属性务必加以设置。
Microsoft Data Link
Microsoft Data Link系被用来访问任何已安装的OLE DB Provider。一个OLE DB Provider要想加入分布式事务中，它必须采用ITransactionJoin接口。
一般来说，于DTS包中使用事务的整个设置流程如下所示：
1. 启用事务
要能够在DTS包中使用事务的第一件事，就是必须如图表2-44所示，于「DTS包属性」对话框的「高级」页面中，勾选复选框 □ 使用事务，此举表示允许在DTS包中定义及使用任务的事务单元；如果您并未勾选此复选框，将没有任何的包事务会被建立，而且步骤要求加入事务的请求亦会被忽略。
图表2-44
2. 将某一个步骤加入包事务
欲将某一个步骤加入包事务，请开启该步骤的「工作流属性」对话框并切换至「选项」页面，然后勾选复选框 □有事务时联接（如图表2-45所示）。此举会将此步骤加入包事务，而且更新将会一直累积直到认可或复原为止。
当一个步骤加入包事务，此步骤所使用的每一个DTS连接也都会加入分布式事务中。这种DTS连接的所有更新将会累积在包事务中，即使它们起源于一个并未加入包事务的步骤。因此，欲于一个包中针对同一个数据库执行事务与非事务的更新，必须使用两个DTS连接。
图表2-45
3. 反复步骤2的操作，直到您已将所需的各个步骤加入包事务为止。
4. 认可或复原
当包事务被认可，所有累积的更新将会实际写入。当发生下列事件之一时，包事务便会被认可：
一个步骤成功地完成而且复选框 □成功完成此步骤时提交事务 被勾选（此复选框位于「工作流属性」对话框的「选项」页面中）。
包成功地完成而且复选框 □ 成功完成包时提交 被勾选（此复选框位于「DTS包属性」对话框的「高级」页面中）。
当包事务被复原，所有累积的更新将会被恢复而视同没有发生过。当发生下列事件之一时，包事务便会被复原：
包 执行失败。
包执行完毕但是该包的 □ 成功完成包时提交 复选框并未被勾选。
某一个步骤执行失败而且该步骤的 □ 失败时回滚事务 复选框被勾选（此复选框位于「工作流属性」对话框的「选项」页面中）。
继承的事务
我们可以在DTS包之工作流的某一个步骤以执行包任务去执行其它的DTS包，内含执行包任务的包称为「父包」（Parent Package），而被执行包任务所执行的包则称为「子包」（Child Package）。子包可以建立它自己的包事务，抑或是继承父包事务。
当下列两项条件皆成立时，子包就可继承父包事务：
子包系被一个执行包任务所调用。
调用子包的执行包任务亦加入父包事务中。
如图表2-46所示，其中的6个包全部使用事务。每一个包其实都内含数个任务，但是我们仅标示出执行包任务。包A执行包B与C，包B与C则依序执行包D、E与F。已加入包事务的执行包任务会被加上底线。
包A、B与D会在一个包事务中执行；包C与F会在第二个包事务中执行；包E则拥有它自己个别的包事务。
图表2-46
如果以继承的事务执行包，事务行为将有很大的不同，说明如下：
不会有任何新的包事务被启动。步骤会加入继承的父事务中。
不会进行任何认可。特别是：
如果复选框 □ 成功完成此步骤时提交事务 被勾选，则会忽略父事务。
如果复选框 □ 成功完成包时提交 被勾选，则会忽略父事务。
当包完成时不会进行任何复原，即使包执行失败亦是如此。然而，如果您勾选「工作流属性」对话框中的复选框 □ 失败时将事务复原，个别的步骤可能会复原父包事务。
如果一个子包失败，则执行它的执行包任务也会失败。如果一个子包成功地完成，则执行它的执行包任务也会成功地完成。如果一个子包发生许多错误或复原包事务，但是并未勾选其复选框 □第一次出错时使包失败（此选项位于「DTS包属性」对话框的「日志记录」页面中），它将会成功地完成，执行它的执行包任务也会成功地完成。
事务隔离层级
先前定义事务时就曾提及，"隔离"是事务的特性之一，本段落我们就要说明如何去设置事务隔离层级。隔离层级亦指事务准备去接受不一致数据的层级。替您的包设置正确的隔离层级是非常重要的。
隔离层级是一个事务与其它事务隔离的程度。较低的隔离层级可以增加并行性，但却会牺牲数据的正确性。反之，较高的隔离层级可以确保数据是正确的，但会减低并行性。
并行性意指当一个用户去修改数据的同时其它用户目前亦正在修改该数据。您可以透过悲观式并行性或乐观式并行性来解决此一状况。
悲观式并行性会去锁定它所欲读取或更新的数据，而且直到它离开该笔数据时才会解除锁定。因此，锁定的时间可能很长，不过此举可以确保当您在读取该数据时没有任何其它用户能够修改它。
乐观式并行性则是在对数据进行写入时才会去锁定它，因此，您无法确认数据在您读取与更新时是否相同。虽然如此，乐观式并行性只会锁定数据很短的时间，因此有助于数据共享。
先前定义事务时就曾提及，"隔离"是事务的特性之一，本段落我们就要说明如何去设置事务隔离层级。隔离层级亦指事务准备去接受不一致数据的层级。替您的包设置正确的隔离层级是非常重要的。
隔离层级是一个事务与其它事务隔离的程度。较低的隔离层级可以增加并行性，但却会牺牲数据的正确性。反之，较高的隔离层级可以确保数据是正确的，但会减低并行性。
并行性意指当一个用户去修改数据的同时其它用户目前亦正在修改该数据。您可以透过悲观式并行性或乐观式并行性来解决此一状况。
悲观式并行性会去锁定它所欲读取或更新的数据，而且直到它离开该笔数据时才会解除锁定。因此，锁定的时间可能很长，不过此举可以确保当您在读取该数据时没有任何其它用户能够修改它。
乐观式并行性则是在对数据进行写入时才会去锁定它，因此，您无法确认数据在您读取与更新时是否相同。虽然如此，乐观式并行性只会锁定数据很短的时间，因此有助于数据共享。
图表2-47
您可以如图表2-47所示，从「事务隔离层级」下拉列表中选取一选项来设置隔离层级。透过设置事务隔离层级，可以决定在事务外部的异动有多大范围是事务可见的。特别值得一提的是，事务隔离层级是由是否出现下列现象所定义：
Dirty读取（Dirty Read）
Dirty读取意指一个事务读取了未被认可的数据。举例来说，假设事务1更改了一笔数据记录，事务2在事务1认可它所做的修改前读取了该笔已修改的数据记录，如果事务1放弃该项更新，事务2就会读取到逻辑上被视为是不存在的数据记录。
非可重复读取（Nonrepeatable read）
非可重复读取意指当一个事务读取相同的数据记录超过一次以上，而在两次或多次的读取之间有另外一个事务修改此笔数据记录的内容。由于在相同事务内的多次读取之间数据记录已被修改，使得每次读取到不同的数据值，因而造成不一致的问题。
举例来说，假设事务1读取一笔数据记录，事务2修改或删除了该笔数据记录并认可所做的修改或删除，如果事务1尝试再次读取该笔数据记录，所提取的将是不同的数据值或是发现该笔数据记录已被删除。
幻像（Phantom）
某一个任务读取了某一范围的数据记录且尚未认可，尔后有另外一个任务在此范围中新建了一笔数据记录或删除某一笔既存的数据记录，此举将因为该范围中的记录笔数已经改变而导致未认可该事务的任务无法重复其原先的读取作业。如果一个连接将其事务隔离层级设置成Serializable，SQL Server将使用索引键范围锁定来防止幻像。
举例来说，事务1搜寻出符合特定条件的多笔数据记录以便加以读取，尔后事务2新建了一笔符合事务1之搜寻条件的数据记录，如果事务1再次执行搜寻命令，搜寻所得的数据记录将与先前不尽相同。
以下是「事务隔离层级」下拉列表中各个选项的说明：
Chaos
此选项只有当您在DTS中使用非SQL Server数据来源时才会使用到，而且它亦是最危险的选项。如果您的DTS包写入任何数据，而且没有出现任何错误，您将不能够复原所做的更新－－亦即一旦建立就没有办法被恢复。因此，一个以Chaos层级作业的DTS任务事务并无法将您与其它正在使用数据来源的任务单元隔离开来，因此您包中的事务将会见到其它事务所有未认可的异动。如果其它事务后来复原了它们的异动，您的DTS包将不会受影响而且会如同数据已被认可般的继续执行。此外，包执行的任何更新锁定将不会持续到事务结束。
Read Committed
我想这是您最经常使用到的选项，它提供您包最高等级的数据完整性。一个以此隔离层级运行的包不会见到其它事务所做的异动，直到这些事务已认可为止。在此隔离层级中，不可能发生Dirty读取，但是非可重复读取与幻像则是可能发生的。
Read Uncommitted
此选项与Chaos选项有点类似，然而此选项可适用于SQL Server。一个以此隔离层级运行的包将能够见到其它事务所做的异动。在此隔离层级中，Dirty读取、非可重复读取与幻像都是可能发生的。
Repeatable Read
一个以Repeatable Read隔离层级运行的DTS包可保证包内的每一个事务不会见到其它事务对已读取之数据值所做的任何异动。因此，如果一个事务读取相同的数据两次，它将固定见到原始数据。在此隔离层级中，不会发生Dirty读取与非可重复读取，然而幻像则是可能发生的。
Serializable
一个以Serializable隔离层级运行的DTS包可保证所有并行事务交互所产生的结果与个别完整执行每个事务的结果一样。在此隔离层级中， Dirty读取、非可重复读取与幻像皆不会发生。
OLE DB
如果您勾选复选框 □ 使用OLE DB服务组件，表示使用OLE DB服务组件（预设为IDataInitialize::CreateDBInstance）来启始OLE DB Provider数据来源；如果您不勾选复选框 □ 使用OLE DB服务组件，表示直接以CoCreateInstance来启始数据来源对象。
OLE DB服务组件可提供类似任务阶段共享（Session Pooling）与IRowsetChange的服务，但有些OLE DB Provider可能不支持这类服务。DTS提供者（PackageDSO、RowQueue与FlatFile）以及OLE DB Provider for SQL Server会忽略此一设置
