Sql命令（使用“ 0”參數調用“ ExecuteScalar”的異常）

Question

當我第一次嘗試運行以下代碼時，出現無法解釋的錯誤，但是再次嘗試運行腳本可以正常工作……我的代碼有什么問題？

順便說一下，我要在此步驟之前創建數據庫...

  $SqlConnection = New-Object System.Data.SqlClient.SqlConnection
  $SqlConnection.ConnectionString = "Server=$dBServer;Database=$dBName;Integrated Security=True" 
  $SqlConnection.Open() 

  $SqlCmd = New-Object System.Data.SqlClient.SqlCommand 
  $SqlCmd.CommandText = $dBCmd 
  $SqlCmd.Connection = $sqlConnection 

  $execute = $SqlCmd.ExecuteScalar() 
  $SqlConnection.Close() 

錯誤

Exception calling "ExecuteScalar" with "0" argument(s): "A transport-level error has occurred when sending the request to the server. (provider: Shared Memory  Provider, error: 0 - No process is on the other end of the pipe.)" At c:\scripts\DB\Powershell\RunSql.ps1:61 char:34
+   $execute = $sqlCmd.ExecuteScalar <<<< ()
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

Answer 1

如果您嘗試使用服務器重置的連接來執行命令，這是一個常見錯誤。 每當我運行Powershell腳本，重新啟動SQL Server，然后嘗試再次運行該腳本時，我總是會遇到這種情況。 該腳本認為該連接仍處於打開狀態，但是當嘗試使用該連接時，您會收到傳輸級錯誤並關閉該連接。 當您嘗試再次運行腳本時，它將重新建立連接，並且一切正常。

如果要強制其關閉連接，只需在重新啟動SQL Server時執行$ SqlConnection.Close（）語句。

Answer 2

您是否檢查過SQL Server配置管理器以確保啟用了“命名管道”（在“ SQL Server網絡配置-> SQL協議...”下）？

Answer 3

對於我遇到的一個奇怪的情況，我終於通過使用$ error變量而不是（$ LastExitCode或$？）來檢測sql查詢失敗，並在我的代碼在第二次嘗試后循環工作時循環了幾次，從而得出了可接受的解決方案。

$attempts = 0
$maxAttempts = 3

  while ($attempts -lt $maxAttempts)
  {
    $attempts++
    $error.clear() # Clears teh error variable incase of any previous errors in the script

      $SqlConnection = New-Object System.Data.SqlClient.SqlConnection 
      $SqlConnection.ConnectionString = "Server=$dBServer;Database=$dBName;Integrated Security=True"  
      $SqlConnection.Open()  

      $SqlCmd = New-Object System.Data.SqlClient.SqlCommand  
      $SqlCmd.CommandText = $dBCmd  
      $SqlCmd.Connection = $sqlConnection  

      $execute = $SqlCmd.ExecuteScalar()  
      $SqlConnection.Close()  

      if ($error.count -eq 0)
      {
        write-host "Sql Query was Successful."            
        break
      }        

      else
      {   
        write-host "Sql Query failed on attempt $attempts"
        $error.clear()
      }
  }

Answer 4

我遇到了同樣的問題，我設法通過將連接字符串移動到實例化連接的同一行來解決了這個問題。

$SqlConnection = New-Object System.Data.SqlClient.SqlConnection $conString

不知道為什么，但是事后分配它不起作用。 也許有人可以弄清楚為什么？

Answer 5

我認為您可以強制將其直接轉到tcp（1433）並通過使用跳過建立命名管道的連接

“服務器= $ dBServer，1433;數據庫= $ dBName;集成安全性= True”

許多圖書館，客戶首先嘗試使用命名管道，但是通常最佳實踐是僅讓1433監聽目標。 我認為Ozie的代碼也可以工作...很簡單，嘗試命名管道，失敗，嘗試1433，這是MS事情通常的工作方式。 您可以嘗試使用網絡庫等進行fussign，如其他人所描述的那樣，但是使用正確的conn字符串通常是一個好主意，因此您可以知道防火牆所使用的端口。