PowerShell脚本命令行正常，SQL Server代理作业执行报ReportWrongProviderType错误

我碰到过好多次这种情况——脚本在本地PowerShell里跑的好好的，一放到SQL Server代理作业里就炸了，尤其是涉及到DataTable的操作。咱们来一步步解决这个问题：

问题到底出在哪？ #

SQL Server代理默认会加载SQLPS（或者新版本的SqlServer）模块，这个模块会给很多.NET对象套一层"壳"，包括你用到的DataTable。当你直接访问$Datatable.Rows.Count时，SQLPS的类型校验机制就会触发这个"ReportWrongProviderType"错误——它觉得你应该用SQLPS专属的方式操作这些对象，而不是直接调用.NET原生属性。

而你在普通PowerShell命令行里运行时，根本没加载这个模块，所以DataTable是纯原生的.NET对象，自然不会有问题。

方案1：修改脚本里的DataTable判断逻辑 #

咱们先从脚本本身下手，确保操作的是原生的.NET DataTable：

方式A：显式转换为原生类型 #

在用到$Datatable之前，先把它转成纯.NET的System.Data.DataTable，绕开SQLPS的包装：

# 先把SQLPS包装的对象转成原生DataTable
$realDatatable = [System.Data.DataTable]$Datatable
if ($realDatatable.Rows.Count -gt 0) {
    # 你的后续业务代码
}

方式B：更严谨的空值判断 #

如果转换类型还是有问题，可以试试逐层判断，先确认对象和属性都存在，再检查行数：

# 先确保$Datatable和它的Rows属性都不为空，再判断行数
if ($Datatable -ne $null -and $Datatable.Rows -ne $null -and $Datatable.Rows.Count -gt 0) {
    # 你的后续业务代码
}

这种方式能避免直接访问属性时触发SQLPS的类型校验错误。

方案2：让代理用标准PowerShell环境运行脚本 #

如果你的脚本不需要依赖SQLPS模块，那干脆让SQL Server代理用纯PowerShell环境跑：

1. 打开SQL Server代理，找到你的作业，编辑对应的作业步骤。
2. 把"步骤类型"从"PowerShell"改成**"操作系统(CmdExec)"**。
3. 在"命令"框里输入调用PowerShell的命令，指定你的脚本路径：

   powershell.exe -ExecutionPolicy Bypass -File "C:\Your\Script\Path\YourScript.ps1"
   

   这样会启动一个独立的PowerShell进程，完全和你本地命令行的环境一致，再也不会有SQLPS的干扰。

额外提醒 #

• 如果你的脚本必须用SQLPS模块（比如用到了Invoke-SqlCmd这类Cmdlet），记得在脚本开头明确导入模块，并且处理好对象类型的转换。
• 别忘了检查SQL Server代理的运行账号有没有足够的权限——比如访问脚本里的数据库、文件系统之类的，有时候权限不足也会伪装成这种类型错误。

内容的提问来源于stack exchange，提问作者DForck42