Utilisation d'identificateurs SQL Server dans PowerShell
Lorsque vous utilisez le fournisseur SQL Server pour Windows PowerShell avec le moteur de base de données, vous devez fournir le nom de l'ordinateur et de l'instance, même pour les instances par défaut.
Le fournisseur utilise des identificateurs SQL Server dans les chemins d'accès Windows PowerShell . Les identificateurs SQL Server peuvent contenir des caractères que Windows PowerShell ne prend pas en charge dans les chemins d'accès. Vous devez placer ces caractères dans une séquence d'échappement ou leur appliquer un codage spécial lors de l'utilisation des identificateurs dans les chemins d'accès Windows PowerShell.
Noms d'ordinateur
Le premier nœud venant après SQLSERVER:\SQL est le nom de l'ordinateur qui exécute l'instance du moteur de base de données ; par exemple, SQLSERVER:\SQL\MyComputer. Si vous exécutez Windows PowerShell sur le même ordinateur que l'instance du moteur de base de données, vous pouvez utiliser localhost ou (local) à la place du nom de l'ordinateur. Les scripts utilisant localhost ou (local) peuvent être exécutés sur n'importe quel ordinateur, sans qu'il soit nécessaire de les modifier pour refléter différents noms d'ordinateur. Par exemple, cette commande est destinée à l'exemple de base de données AdventureWorks dans l'instance par défaut sur l'ordinateur local :
Set-Location SQLSERVER:\SQL\localhost\DEFAULT\Databases\AdventureWorks
Les parenthèses contenues dans (local) sont normalement traitées comme des commandes par Windows PowerShell. Vous devez donc effectuer l'une des opérations suivantes :
mettre les chaînes de chemin d'accès entre guillemets ;
Set-Location "SQLSERVER:\SQL\(local)\DEFAULT\Databases\AdventureWorks"échapper la parenthèse à l'aide du caractère « ` » (backtick) ;
Set-Location SQLSERVER:\SQL\`(local`)\DEFAULT\Databases\AdventureWorkscoder la parenthèse à l'aide de leur représentation hexadécimale.
Set-Location SQLSERVER:\SQL\%28local%29\DEFAULT\Databases\AdventureWorks
Les caractères d'échappement et de codage sont détaillés plus loin dans cette rubrique.
Vous ne pouvez pas utiliser un point (.) pour spécifier l'ordinateur local dans les scripts Windows PowerShell. Le point n'est pas pris en charge car Windows PowerShell l'interprète comme une commande.
Noms d'instances par défaut
Vous pouvez exécuter plusieurs instances du programme exécutable du moteur de base de données sur le même ordinateur. Les instances du Moteur de base de données sont identifiées par la combinaison du nom de l'ordinateur et d'un nom d'instance, tels que MonOrdinateur\MonInstance.
Chaque ordinateur peut avoir une instance par défaut du Moteur de base de données. Vous ne spécifiez pas de nom pour l'instance par défaut lorsque vous l'installez. Si vous spécifiez seulement un nom d'ordinateur dans une chaîne de connexion, vous êtes connecté à l'instance par défaut sur cet ordinateur. Toutes les autres instances sur l'ordinateur doivent être des instances nommées. Vous spécifiez le nom de l'instance pendant l'installation, et les chaînes de connexion doivent spécifier à la fois le nom d'ordinateur et le nom de l'instance.
Le fournisseur SQL Server requiert que vous spécifiiez toujours un nom d'instance. Pour les instances par défaut, vous devez spécifier le nom d'instance DEFAULT.
Identificateurs SQL Server dans les chemins d'accès Windows PowerShell
Les fournisseurs Windows PowerShell présentent les hiérarchies de données à l'aide d'une structure de chemin d'accès semblable à celle utilisée pour le système de fichiers Windows. Le fournisseur SQL Server implémente les chemins d'accès aux objets SQL Server. Pour le moteur de base de données, le lecteur est défini sur SQLSERVER:, le premier dossier est défini sur \SQL et les objets de base de données sont référencés sous forme de conteneurs et d'éléments. Voici le chemin d'accès à la table Vendor dans le schéma Purchasing de la base de données AdventureWorks dans une instance par défaut du Moteur de base de données:
SQLSERVER:\SQL\MyComputer\DEFAULT\Databases\AdventureWorks\Tables\Purchasing.Vendor
Les identificateurs SQL Server sont les noms des objets SQL Server, tels que des noms de tables ou de colonnes. Il existe deux types d'identificateurs SQL Server :
Les identificateurs standard sont limités à un jeu des caractères qui sont également pris en charge dans les chemins d'accès Windows PowerShell. Ces noms peuvent être utilisés dans les chemins d'accès Windows PowerShell sans être modifiés.
Les identificateurs délimités peuvent utiliser des caractères non pris en charge dans les noms de chemins d'accès Windows PowerShell. Ils sont appelés « identificateurs entre crochets » s'ils sont placés entre crochets ([NomIdentificateur]) et « identificateurs entre guillemets » s'ils sont placés entre les guillemets ("NomIdentificateur"). Si un identificateur délimité utilise des caractères non pris en charge dans les chemins d'accès Windows PowerShell, les caractères doivent être codés ou placés dans une séquence d'échappement avant d'utiliser l'identificateur comme conteneur ou nom d'élément. Le codage fonctionne pour tous les caractères. Certains caractères, tels que le caractère deux-points (:), ne peuvent pas être placés dans une séquence d'échappement.
Codage et décodage d'identificateurs
Les caractères qui ne sont pas pris en charge dans les noms de chemins d'accès Windows PowerShell peuvent être représentés, ou codés, sous la forme du caractère « % » suivi de la valeur hexadécimale pour le modèle binaire qui représente le caractère, comme dans « **%**xx ». Le codage peut toujours être utilisé pour gérer des caractères qui ne sont pas pris en charge dans les chemins d'accès Windows PowerShell.
L'applet de commande Encode-SqlName prend comme entrée un identificateur SQL Server. Elle génère une chaîne contenant tous les caractères qui ne sont pas pris en charge par le langage Windows PowerShell codés avec « % xx ». L'applet de commande Decode-SqlName prend comme entrée un identificateur SQL Server codé et retourne l'identificateur d'origine. Par Exemple :
Cette commande retourne la chaîne « Table%3ATest » :
Encode-SqlName "Table:Test"Cette commande retourne «Table:Test » :
Decode-SqlName "Table%3ATest"
Lorsque vous spécifiez des identificateurs délimités dans les applets de commande Windows PowerShell, vous pouvez soit fournir vous-même les valeurs de caractère codés, soit utiliser Encode-SqlName pour fournir les caractères codés. Par exemple, si vous avez déjà navigué jusqu'au schéma qui contient la table [Table:Test], vous pouvez activer le répertoire (cd) de la table en fournissant la version codée du caractère « : » :
Set-Location Table%3ATest
Vous pouvez également utiliser Encode-SqlName pour générer un nom pris en charge par PowerShell:
Set-Location (Encode-SqlName "Table:Test")
Voici les caractères codés par Encode-SqlName et décodés par Décode-SqlName :
Caractère |
\ |
/ |
: |
% |
< |
> |
* |
? |
[ |
] |
| |
Codage hexadécimal |
%5C |
%2F |
%3A |
%25 |
%3C |
%3E |
%2A |
%3F |
%5B |
%5D |
%7C |
Caractères d'échappement
Vous pouvez souvent utiliser le caractère d'échappement Windows PowerShell « ` » (backtick) pour placer dans une séquence d'échappement les caractères qui sont autorisés dans les identificateurs délimités SQL Server, mais pas les noms de chemins d'accès Windows PowerShell. Certains caractères ne peuvent toutefois pas être placés dans une séquence d'échappement. Par exemple, vous ne pouvez pas placés dans une séquence d'échappement le caractère deux-points (:) dans Windows PowerShell. Les identificateurs contenant ce caractère doivent être codés. Le codage est plus fiable que l'utilisation d'une séquence d'échappement, car le codage fonctionne pour tous les caractères.
Voici un exemple de séquence d'échappement pour le caractère # :
cd SQLSERVER:\SQL\MyComputer\MyInstance\MyDatabase\MySchema\`#MyTempTable
Le caractère ` (backtick) se trouve généralement sur une touche située dans la partie supérieure gauche du clavier, sous la touche Échap.
Identificateurs SQL Server dans les applets de commande
Certaines applets de commande SQL Server ont un paramètre qui prend un identificateur comme d'entrée. Les valeurs de paramètres sont généralement fournies sous forme de constantes de chaîne entre guillemets ou dans des variables chaîne. Lorsque les identificateurs sont fournis sous forme de constantes de chaîne ou dans des variables, il n'y a aucun conflit avec le jeu de caractères pris en charge par Windows PowerShell.