web-dev-qa-db-fra.com

La commande SQLCMD n'est pas en mesure d'insérer des accents

J'essaie d'exécuter sqlcmd.exe afin de configurer une nouvelle base de données à partir de la ligne de commande. J'utilise SQL SERVER Express 2012 sur Windows 7 64 bits.

Voici la commande que j'utilise:

SQLCMD -S .\MSSQLSERVER08 -V 17 -E -i %~dp0\aqualogyDB.sql -o %~dp0\databaseCreationLog.log

Et voici un morceau du script de création de fichier sql:

    CREATE DATABASE aqualogy 
    COLLATE Modern_Spanish_CI_AS
    WITH TRUSTWORTHY ON, DB_CHAINING ON;
    GO
    use aqualogy
    GO
    CREATE TABLE [dbo].[BaseLayers] (
    [Code] nchar(100) NOT NULL ,
    [Geometry] nvarchar(MAX) NOT NULL ,
    [IsActive] bit NOT NULL DEFAULT ((1)) 
    )

    EXEC sp_updateextendedproperty @name = N'MS_Description', @value = N'Capas de     cartografía base de la aplicaicón. Consideramos en Galia Móvil la cartografía(...)'
, @level0type = 'SCHEMA', @level0name = N'dbo'
, @level1type = 'TABLE', @level1name = N'BaseLayers'

Eh bien, veuillez vérifier qu'il y a des accents sur les mots; qui est la description du tableau. La base de données est créée sans problème. 'Assembler' est compris par le script, comme vous pouvez le voir sur la capture d'écran ci-jointe. Malgré cela, les accents ne sont pas correctement affichés lors de l'examen du tableau.Collation problem

J'apprécierais vraiment toute aide. Merci beaucoup.

[Modifier]: Salut à tous. Changer l'encodage du fichier SQL à l'aide de Notepad ++ a bien fonctionné! Merci beaucoup pour votre aide: j'ai appris quelque chose d'intéressant avec ce problème!

enter image description here

sql-serversqlcmdsql-server-2012encoding
20
Oskytar

À partir des commentaires, le problème n'est pas exactement avec la table ou la façon dont SQLCMD importe les caractères spéciaux. Habituellement, les importations problématiques sont liées au format du script lui-même.

Management Studio lui-même offre la possibilité d'enregistrer avec un encodage spécifique, ce qui devrait résoudre le problème à l'avenir. Lorsque vous enregistrez un fichier pour la première fois (ou utilisez Enregistrer sous), vous devez cliquer sur la petite flèche près du bouton Enregistrer, pour utiliser l'option Enregistrer avec encodage.

enter image description here

Par défaut, il enregistre le fichier dans Europe de l'Ouest (1252). Chaque fois que j'ai des caractères spéciaux, j'utilise UTF8 (bien que peut-être un autre codage restrictif convienne) car c'est généralement la solution la plus rapide.

enter image description here

Je ne suis pas sûr (d'après la photo) que vous utilisez SSMS, alors assurez-vous que votre propre éditeur a la possibilité d'enregistrer le fichier dans un encodage différent. Sinon, la conversion du fichier dans un éditeur intelligent (comme vous l'avez déjà essayé dans Notepad ++) fonctionne généralement. Bien que cela puisse ne pas fonctionner si vous convertissez un encodage large en un encodage plus étroit, puis de nouveau en un large (par exemple: de Unicode à ANSI et de retour à Unicode).

9
Marian

Une autre option, que je viens d'apprendre, vient de la documentation sqlcmd . Vous devez définir la page de code pour sqlcmd pour qu'elle corresponde à celle du codage du fichier. Dans le cas de l'UTF-8, la page de code est 65001 donc vous voudriez:

SQLCMD -S .\MSSQLSERVER08 -V 17 -E -i %~dp0\aqualogyDB.sql -o %~dp0\databaseCreationLog.log -f 65001

41
swasheck

Ce genre de chose est très délicat car on fait tellement de choses sans vous le dire.

La première chose que je ferais serait d'utiliser sqlcmd pour afficher la chaîne. S'il s'affiche correctement dans la fenêtre cmd.exe, c'est un fait utile. Ensuite, je sélectionnerais la ligne converting la chaîne à varbinary pour voir quels octets sont réellement là. Je pense que cartografía apparaîtra comme 0x636172746f67726166c3ad61, Où le "i" accentué est représenté par les octets c3ad, qui est l'encodage UTF-8 pour ce caractère. Ce n'est pas bon d'avoir UTF-8 dans une colonne d'espagnol moderne (Windows 1252). La valeur d'octet dans Windows 1252 pour ce caractère est 237 décimal (hex ED).

Si la colonne contient des données mal codées, l'erreur réside dans la façon dont elles ont été insérées. Peut-être que la suppression du N de tête dans les constantes de chaîne - N'string' Indique à SQL Server de générer une chaîne Unicode, mais un simple 'string' Indique que les caractères utilisent l'encodage du client - insérerait l'espagnol moderne au lieu d'Unicode .

Si la colonne contient des données correctement encodées, je dirais que vous avez trouvé un bogue dans l'affichage de l'interface graphique.

Si vous ne parvenez pas à obtenir sqlcmd pour insérer correctement les données (en tête N ou non), vous souhaitez vous plaindre auprès de Microsoft. Lorsque vous le faites, être en mesure d'afficher les octets tels qu'ils sont stockés dans la colonne - en utilisant convert(colname as varbinary) - sera essentiel pour expliquer ce qui ne va pas.

2
James K. Lowden

Cela a fonctionné pour moi, mais pour une raison quelconque, la commande -f 65001 n'a pas fonctionné.

sqlcmd -s serverName -f i:1252 -i c:\sqlUpdate.sql -f o:65001 -o c:\sqlUpdateOutput.sql -d userDatabaseName
0
Tequila