DTS包在何处运行？
为什么DTS包成了作业以后就不能正确运行了呢？我们从企业管理器中运行的时候一切正常，但我们把它当成一个作业的时候就不行了。因为它运行不同的环境里，这个环境指的是security context，安全环境或安全上下文。作为程序员你可以在一台工作站前运行程序，那DTS所处的环境就是你面前机器的环境，但如果作为作业，它始终运行在服务器上。
作为程序员，你可以希望从一个文本文件中导入数据，但是DTS中指定的文件必须也存在于服务器上，而且必须有足够的权限支持对这个文件的操作。
那到底是谁运行了DTS包呢？是一个称为SQL Agent的服务，这个作业有一个拥有者，这个拥有者可以是一个SQL SERVER登录也可以是一个NT帐户。可以通过企业管理器来直接查看所有者是谁，也可以通过运行msdb.dbo.sp_help_job来获知谁是拥有者。
对于SQL Server 7.0来说，安全上下文是由作业的所有者决定的。如果所有者是一个不必于Sysadmin角色的用户，包就在SQLAgentCmdExec帐户下运行，当然使用的安全上下文也就是这个帐户的，因此这个帐户必须拥有足够的权限才能够运行指定的操作。通常而言，SQLAgentCmdExec帐户不拥有对服务器以外计算机的权限，因此对别的机器上文件的访问当然就要失败了。
对于SQL Server 2000来说，安全上下文也是作业的拥有者决定。如果所有者是一个不必于Sysadmin角色的用户，包就在SQL Agent Proxy帐户下运行，也使用此用户的权限。对于SQL Agent Proxy来说，它可以运行与数据库相连的操作，当然它也必须拥有相应的数据库和NT权限。对于执行DTS包来说，SQL Agent Proxy Account必须拥有对帐户运行临时目录的读写权限，这也目录是：c:\Documents and Settings\<Account>\Local Settings\Temp
如果作业是被Sysadmin数据库角色的成员拥有，作业即在启动SQL Agent服务的帐户下运行。同时，如果作用被NT域用户拥有，而且包被存储于数据库，你必须使用在同一域或信任域的用户启动SQL Server服务。例如，如果SQL Agent作业由USA域用户所有，那启动SQL Server服务的用户必须是来自USA域或USA域的信任域。如果SQL Server由本地帐户启动，包的执行将失败。如果调度一个DTS包，此时它的拥有者将是谁？此时的拥有者要看登录企业管理器时谁进行了登录，如果数据库使用NT认证，作业的主将是启动SQL Agent服务的NT帐户；如果登录企业管理器的时候使用SQL Server认证（如利用SA登录），那主将是这个SQL SERVER用户。如果希望改变包的拥有者，可以在企业管理中实现，直接右键一击，在”通用“下面就是了。而在查询分析器中则要使用msdb.dbo.sp_update_job来进行。
DTS如果通过DTSRUN.exe运行，那安全上下文就是此时登录计算机的用户。如果通过xp_cmdshell运行如果DTSRUN.exe，如果此用户是Sysadmin角色中的用户，他启动了SQL Server服务，他就是安全上下文。如果是这个用户不是Sysadmin角色中的用户，则DTSRun.exe在SQLAgentCmdExec帐户中运行。如果SQL SERVER以本地帐户启动，DTS包不拥有访问其它机器资源的权限。
如果SQL Server服务在NT帐户下启动，它的权限和NT帐户的权限一致。如果此帐户是一个本地帐户，DTS包不拥有对其它机器的权限；如果此帐户是一个域用户，包可以访问域内其它计算机的资源。有时在DTS包中我们使用一个NT认证连接，此连接的安全上下文与包运行的安全上下文一致。如果在命令行上运行DTSRun.exe，此进行获得的安全证书是当前NT登录用户的证书。如果包以一个作业运行，此连接的安全上下文将是启动SQL Agent的帐户，我们假设包的拥有者是Sysadmin的成员。
我们映射驱动器时包运行会出错，因为映射的驱动器不是物理存在的，而SQL Agent是一个NT服务，NT服务是无法看到映射驱动器的。映射是用户脚本的一部分，服务不会调用用户脚本的内容，请使用UNC路径来解决其它机器上资源的调用。相对路径也最好不要使用，因为DTS包的运行将由调试机转移到服务器，因此相对路径不好用。至于COM组件的使用，一定要确定服务器上也有相应的COM组件。虽然包本身也有一些密码要提供，如包拥有者的密码和用户密码，这些东西和运行环境没有关系。SQLAgentCmdExec的权限如果不足以运行包，会产生下面的错误信息：
DTSRun: Loading... DTSRun: Executing... DTSRun OnStart: DTSStep_DTSExecuteSQLTask_1 DTSRun OnError: DTSStep_DTSExecuteSQLTask_1, Error = -2147217843 (80040E4D) Error string: Login failed for user 'NT_name\SQLAgentCmdExec'. Error source: Microsoft OLE DB Provider for SQL Server Help file: Help context: 0 Error Detail Records: Error: -2147217843 (80040E4D); Provider Error: 18456 (4818) Error string: Login failed for user 'NT_name\SQLAgentCmdExec'. Error source: Microsoft OLE DB Provider for SQL Server Help file: Help context: 0 DTSRun OnFinish: DTSStep_DTSExecuteSQLTask_1 DTSRun: Package execution complete. Process Exit Code 1. The step failed.
你必须给SQLAgentCmdExec足够的登录权利和数据库权限。
为什么DTS包成了作业以后就不能正确运行了呢？我们从企业管理器中运行的时候一切正常，但我们把它当成一个作业的时候就不行了。因为它运行不同的环境里，这个环境指的是security context，安全环境或安全上下文。作为程序员你可以在一台工作站前运行程序，那DTS所处的环境就是你面前机器的环境，但如果作为作业，它始终运行在服务器上。
作为程序员，你可以希望从一个文本文件中导入数据，但是DTS中指定的文件必须也存在于服务器上，而且必须有足够的权限支持对这个文件的操作。
那到底是谁运行了DTS包呢？是一个称为SQL Agent的服务，这个作业有一个拥有者，这个拥有者可以是一个SQL SERVER登录也可以是一个NT帐户。可以通过企业管理器来直接查看所有者是谁，也可以通过运行msdb.dbo.sp_help_job来获知谁是拥有者。
对于SQL Server 7.0来说，安全上下文是由作业的所有者决定的。如果所有者是一个不必于Sysadmin角色的用户，包就在SQLAgentCmdExec帐户下运行，当然使用的安全上下文也就是这个帐户的，因此这个帐户必须拥有足够的权限才能够运行指定的操作。通常而言，SQLAgentCmdExec帐户不拥有对服务器以外计算机的权限，因此对别的机器上文件的访问当然就要失败了。
对于SQL Server 2000来说，安全上下文也是作业的拥有者决定。如果所有者是一个不必于Sysadmin角色的用户，包就在SQL Agent Proxy帐户下运行，也使用此用户的权限。对于SQL Agent Proxy来说，它可以运行与数据库相连的操作，当然它也必须拥有相应的数据库和NT权限。对于执行DTS包来说，SQL Agent Proxy Account必须拥有对帐户运行临时目录的读写权限，这也目录是：c:\Documents and Settings\<Account>\Local Settings\Temp
如果作业是被Sysadmin数据库角色的成员拥有，作业即在启动SQL Agent服务的帐户下运行。同时，如果作用被NT域用户拥有，而且包被存储于数据库，你必须使用在同一域或信任域的用户启动SQL Server服务。例如，如果SQL Agent作业由USA域用户所有，那启动SQL Server服务的用户必须是来自USA域或USA域的信任域。如果SQL Server由本地帐户启动，包的执行将失败。如果调度一个DTS包，此时它的拥有者将是谁？此时的拥有者要看登录企业管理器时谁进行了登录，如果数据库使用NT认证，作业的主将是启动SQL Agent服务的NT帐户；如果登录企业管理器的时候使用SQL Server认证（如利用SA登录），那主将是这个SQL SERVER用户。如果希望改变包的拥有者，可以在企业管理中实现，直接右键一击，在”通用“下面就是了。而在查询分析器中则要使用msdb.dbo.sp_update_job来进行。
DTS如果通过DTSRUN.exe运行，那安全上下文就是此时登录计算机的用户。如果通过xp_cmdshell运行如果DTSRUN.exe，如果此用户是Sysadmin角色中的用户，他启动了SQL Server服务，他就是安全上下文。如果是这个用户不是Sysadmin角色中的用户，则DTSRun.exe在SQLAgentCmdExec帐户中运行。如果SQL SERVER以本地帐户启动，DTS包不拥有访问其它机器资源的权限。
如果SQL Server服务在NT帐户下启动，它的权限和NT帐户的权限一致。如果此帐户是一个本地帐户，DTS包不拥有对其它机器的权限；如果此帐户是一个域用户，包可以访问域内其它计算机的资源。有时在DTS包中我们使用一个NT认证连接，此连接的安全上下文与包运行的安全上下文一致。如果在命令行上运行DTSRun.exe，此进行获得的安全证书是当前NT登录用户的证书。如果包以一个作业运行，此连接的安全上下文将是启动SQL Agent的帐户，我们假设包的拥有者是Sysadmin的成员。
我们映射驱动器时包运行会出错，因为映射的驱动器不是物理存在的，而SQL Agent是一个NT服务，NT服务是无法看到映射驱动器的。映射是用户脚本的一部分，服务不会调用用户脚本的内容，请使用UNC路径来解决其它机器上资源的调用。相对路径也最好不要使用，因为DTS包的运行将由调试机转移到服务器，因此相对路径不好用。至于COM组件的使用，一定要确定服务器上也有相应的COM组件。虽然包本身也有一些密码要提供，如包拥有者的密码和用户密码，这些东西和运行环境没有关系。SQLAgentCmdExec的权限如果不足以运行包，会产生下面的错误信息：
DTSRun: Loading... DTSRun: Executing... DTSRun OnStart: DTSStep_DTSExecuteSQLTask_1 DTSRun OnError: DTSStep_DTSExecuteSQLTask_1, Error = -2147217843 (80040E4D) Error string: Login failed for user 'NT_name\SQLAgentCmdExec'. Error source: Microsoft OLE DB Provider for SQL Server Help file: Help context: 0 Error Detail Records: Error: -2147217843 (80040E4D); Provider Error: 18456 (4818) Error string: Login failed for user 'NT_name\SQLAgentCmdExec'. Error source: Microsoft OLE DB Provider for SQL Server Help file: Help context: 0 DTSRun OnFinish: DTSStep_DTSExecuteSQLTask_1 DTSRun: Package execution complete. Process Exit Code 1. The step failed.
你必须给SQLAgentCmdExec足够的登录权利和数据库权限。
