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.

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!

À 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 .

Par défaut, il enregistre le fichier en Europe occidentale (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.

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).

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

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

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 de convertla chaîne dans 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 le codage 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 premier N dans les constantes de chaîne - N'string'indique à SQL Server de générer une chaîne Unicode, mais 'string'indique simplement 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 les données correctement (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 - à l'aide convert(colname as varbinary)- sera essentiel pour expliquer ce qui ne va pas.