La Commande Sql (à l'Exception de l'appel “ExecuteScalar” avec “0” argument)

Lorsque j'exécute le code ci-dessous sur la première tentative, j'obtiens une erreur inexpliquée, mais l'exécution du script à nouveau lors d'une deuxième tentative fonctionne très bien...ce serait une erreur dans mon code?

Par la façon dont je suis la création de la base de données avant cette étape...

  $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()

Erreur 

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
InformationsquelleAutor Ozie Harb | 2010-03-04
  1. 5

    C'est une erreur courante qui se produit si vous essayez d'exécuter une commande en utilisant une connexion a été réinitialisée par le serveur. Ça m'arrive tout le temps chaque fois que j'exécute un script Powershell, redémarrez le Serveur SQL, et puis essayer de l'exécuter à nouveau le script. Le script pense que la connexion est toujours ouverte, mais quand il essaie de l'utiliser vous obtenez une erreur de niveau transport et il ferme la connexion. Lorsque vous essayez d'exécuter à nouveau le script, il ré-établir la connexion et tout fonctionne bien.

    Si vous voulez forcer la fermeture de la connexion, il suffit d'exécuter l' $SqlConnection.Close() déclaration chaque fois que vous redémarrez le serveur SQL server.

    • Toutes mes excuses pour la réponse tardive, mais pensé a alerte email vérifier... j'ai essayé de mettre un redémarrage du service, il a travaillé pour le couple de tentatives ensuite, il suffit d'avoir le même problème à nouveau...j'ai Donc essayé de mettre $lastExitCode vérifier en cas de thier a été une erreur, mais je reçois le numéro 3 conditions de la requête sql exécutée avec succès ou non. J'ai fatigué d'utiliser $sqlConnection.Close() avant l'ouverture d'une nouvelle connexion, mais pas encore de l'espoir.
    InformationsquelleAutor Greg Bray
  2. 0

    Avez-vous vérifié le Gestionnaire de Configuration SQL Server pour s'assurer que les Tubes Nommés" est activé (dans la section "Configuration du Réseau SQL Server -> Protocoles pour SQL...")?

    • Et parfois, il pourrait être parce que le service explorateur Sql ne fonctionne pas ou n'est pas autorisé dans les exceptions du Pare-feu.
    • Toutes mes excuses pour la réponse tardive, mais pensé a alerte email vérifié, Oui les canaux nommés est activé.
    InformationsquelleAutor Keith Hill
  3. 0

    Pour mon cas étrange que j'ai eu je suis finalement arrivé à une solution acceptable par l'utilisation de $variable d'erreur au lieu de ($LastExitCode ou $?) pour détecter les requêtes sql échec et boucle pour les quelques tentatives que mon code fonctionne après la deuxième tentative.

    $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()
      }
  }
    InformationsquelleAutor Ozie Harb
  4. 0

    Je pense que vous pouvez le forcer à aller directement à tcp(1433) et passez de faire une connexion de canaux nommés par l'aide de

    "Server=$dBServer,1433;Database=$dBName;Integrated Security=True"

    De nombreuses bibliothèques,les clients tentent de canaux nommés en premier, mais en général, la meilleure pratique est seul à avoir 1433 à l'écoute sur votre cible. Je pense que les Ozie code fonctionne aussi...il est simple d'essayer de canaux nommés, à défaut, en essayant 1433 qui est la façon standard de MS choses souvent de travail. Vous pouvez essayer de fussign avec réseau libaries etc comme d'autres l'ont décrit, mais en utilisant le droit de conn chaîne est généralement une bonne idée si vous connaissez le port que vous utilisez pour les pare-feux, etc.

    InformationsquelleAutor Forrest
  5. 0

    J'ai eu ce même problème, j'ai réussi à le résoudre par le déplacement de la chaîne de connexion à la même ligne de où la connexion est instancié.

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

    Ne sais pas pourquoi, mais en l'assignant par la suite ne fonctionne pas. Peut-être que quelqu'un peut jeter un peu de lumière sur le pourquoi?

    InformationsquelleAutor LordWabbit