Question

当我尝试执行SQL Server 2012 BCP.exe实用程序以使用exe的完全限定路径将表的内容转储到文件时，

D:\SQL2012\110\Tools\Binn\bcp.exe DBNAME.DBO.TABLENAME OUT %FileServerProject%\IMPLEMENTATION\DAT\Pre_Run_BaseTables\CDB_ACCT_CURR.DAT -S%SqlServer% -T -N >> %LogFolder%\Log.log

...我收到 ACCESS DENIED 错误。

但是，当我删除exe的完全限定路径并运行时，

bcp.exe DBNAME.DBO.TABLENAME OUT %FileServerProject%\IMPLEMENTATION\DAT\Pre_Run_BaseTables\CDB_ACCT_CURR.DAT -S%SqlServer% -T -N >> %LogFolder%\Log.log

工作正常。

如果路径不合格，我的理解是Windows将搜索PATH环境变量中指定的每个文件夹，查找指定的exe，并执行第一个找到的文件夹。因此，我从控制台执行以下命令以查看我的PATH变量。

ECHO %PATH%

清理输出中的各种不相关路径，我看到以下顺序返回以下SQL相关文件夹：

D:\SQL2012\110\DTS\Binn\;
D:\SQL2012 (86)\110\Tools\Binn\;
D:\SQL2012\110\Tools\Binn\;

后一个Tools\Binn路径是唯一包含bcp.exe实用程序的文件夹。

我的问题是：

由于执行了相同的EXE，无论我是通过搜索路径变量显式限定路径还是让Windows找到它，为什么我在使用完全限定路径运行时得到ACCESS DENIED错误而不是在我没有符合条件时路径？

请注意，在这两种情况下，我都使用对TOOLS\BINN文件夹具有读取和执行权限的ID运行。在我使用完全限定路径的情况下，如果我将帐户添加到本地组，它将起作用，但这不是一个可行的解决方案。此外，该ID对服务器具有LogOn As Batch权限。

更新

我现在毫不怀疑当我使用非限定bcp.exe路径执行时，我实际上在服务器上运行bcp.exe的唯一副本。对于初学者，我使用搜索所有内容来广泛搜索服务器上的每个驱动器。我发现了三次。然后我重命名了我不想意外引用的那个。

然后，我使用不合格的bcp.exe路径重新开始工作，并使用任务管理器的流程标签，我发现bcp.exe在服务帐户下运行。然后我右键单击文件名并选择上下文菜单＆＃34;打开文件位置＆＃34;，它将我带到了bcp.exe文件的唯一未重命名的位置 - 该文件我故意试图用完全限定的名字来定位。

D:\SQL2012\110\Tools\Binn

由于bcp.exe未合格，因此成功运行。

更新2 到目前为止，已有42人对此进行了调查。我很好奇，如果人们正在看这句话，那是不可能的，这个案子的事实不一定与我所说的完全一样。＆＃34;

几乎就在那里： 我将批处理文件简化为最低限度以重现问题。你会注意到我改变了我们的真实路径名，但我保留了它的要点。

在这里＆＃34;之前＆＃34;代码：

 ----------------------------------------------------------------
 Output of messages for workload object TESTDUMP/GHG9999I.11/MAIN
 Start date Fri Sep 25 13:33:36 2015
 ----------------------------------------------------------------

 C:\Users\MyServiceAccount>WHERE bcp.exe 
 INFO: Could not find files for the given pattern(s).

 C:\Users\MyServiceAccount> D:\SQL2012\110\Tools\Binn\bcp.exe  MyDB.DBO.MyTable OUT \\MyFileServer\IMData\MyDB_SOURCE\IMPLEMENTATION\DAT\Pre_Run_BaseTables\MyTable.DAT -S MyDbServer\int -T -N  1>>\\MyFileServer\IMData\MyDB_SOURCE\Logs\MyTable_BCP_out.log 
 Access is denied.

 C:\Users\MYSERVICEACCOUNT>ECHO RESULT=1 
 RESULT=1

这是＆＃34;之后，＆＃34;，哪个有效

 ----------------------------------------------------------------
 Output of messages for workload object TESTDUMP/GHG9999I.10/MAIN
 Start date Fri Sep 25 13:33:00 2015
 ----------------------------------------------------------------

 C:\Users\MyServiceAccount>WHERE bcp.exe 
 INFO: Could not find files for the given pattern(s).

 C:\Users\MyServiceAccount>"D:\SQL2012\110\Tools\Binn\bcp.exe" MyDB.DBO.MyTable OUT \\MyFileServer\IMData\MyDB_SOURCE\IMPLEMENTATION\DAT\Pre_Run_BaseTables\MyTable.DAT -S MyDbServer\int -T -N  1>>\\MyFileServer\IMData\MyDB_SOURCE\Logs\MyTable_BCP_out.log 

 C:\Users\MYSERVICEACCOUNT>ECHO RESULT=0 
 RESULT=0

请注意，不同之处在于工作的BCP路径用引号括起来。我原本以为只有当路径包含嵌入空格时，这才会很重要。我很困惑为什么在这种情况下很重要。

第二个新问题是WHERE命令在MYSERVICDEACCOUNT下通过调度程序运行时失败的原因。当我在MYLANID下手动登录时，该命令有效，导航到c:\users\mylanid并尝试使用。

如果有人能解释为什么报价很重要，他们会得到100分和我的感激之情。

更新4：

我将AgentParm.txt文件放在相同代码工作的服务器上。它位于Program Files文件夹下：

# Agent settings for nt-x86-64
agentname=MyWorkingServer
log.archive=2
oscomponent.jvm=server

在我们讨论批处理文件未引用时我遇到问题的服务器上，我在Program Files（x86）文件夹中看到以下内容。所有其他行都是相同的，所以我排除了它们。我没有看到任何提到的oscomponent.cmdprefix.force.quotes.full。

# Agent settings for nt-x86-32

agentname=MyServer

我是否需要64位版本的CA调度程序来运行64位exes？如果是这样，我是否会遇到使用64位CW Scheduler运行32位exes（如SQL Server dtexec.exe）的问题？

Answer 1

它可能与您指出的内容有关吗？可能是无意中

32Bit D:\SQL2012 (86)\110\Tools\Binn\ 64位D:\SQL2012\110\Tools\Binn\您的硬路径正在调用64位，而您的%PATH%变量首先找到32位版本。

Answer 2

我不熟悉CA Workload Automation调度程序，但是在指定作业时是否使用其JIL语法？

搜索支持文档似乎表明冒号（“：”）是JIL中的特殊字符，需要通过引号或反斜杠进行转义。

Rule 5
Valid value settings can include any of the following characters:
■ Uppercase and lowercase letters (A-Z, a-z)
■ Hyphens (-)
■ Underscores (_)
■ Pound signs (#)
■ Numbers (0-9)
■ Colons (:), if the colon is escaped with quotation marks (" ") or a preceding backslash (\)
■ The at character (@)
Note: Object names can only contain the following characters: a-z, A-Z, 0-9, period (.), underscore (_), hyphen (-), and pound (#). Do not include embedded spaces or tabs.

Answer 3

这与您描述的情况不完全相同，但似乎它可能具有相同的根本原因和修复。 documentation here（p45）描述了一种情况，即在引用时，具有合格路径的作业在Windows中传递给CA Workload Automation Agent时会出现意外行为。这适用于带空格和不带空格的路径。

简而言之 - 似乎已经通过向agentparm.txt文件添加参数oscomponent.cmdprefix.force.quotes.full来修复，您可以将其设置为true或false，具体取决于您的行为想。

所描述的情况并非完全与您匹配，因此我并非100％确定这是一个修复，但是值得切换该设置是为了测试它是否切换了您观察到的行为。

仅在完全限定exe路径时才会发出权限问题。为什么不总是？

3 个答案: