O comando SQLCMD não pode inserir acentos

19

Estou tentando executar o sqlcmd.exe para configurar um novo banco de dados na linha de comando. Estou usando o SQL SERVER Express 2012 no Windows 7 de 64 bits.

Aqui está o comando que eu uso:

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

E aqui está uma parte do script de criação de arquivo 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'

Bem, por favor, verifique se há alguns acentos nas palavras; qual é a descrição da tabela. O banco de dados é criado sem problemas. 'Agrupar' é entendido pelo script, como você pode ver na imagem em anexo. Apesar disso, os acentos não são mostrados corretamente ao examinar a tabela.Problema de agrupamento

Eu realmente aprecio qualquer ajuda. Muito obrigado.

[Editar]: Olá a todos. Alterar a codificação do arquivo SQL usando o Notepad ++ funcionou bem! Muito obrigado pela ajuda: aprendi algo interessante com esse problema!

insira a descrição da imagem aqui

Oskytar
fonte
1
Qual é a codificação do seu arquivo de script SQL?
Pondlife
Eu iria com a idéia de @ Pondlife. Pegue um editor de texto (como o Notepad ++), abra o arquivo .sql lá, vá para Codificação e veja se o seu arquivo não está no ANSI (ou em alguma outra codificação não suportada). Se for, escolha converter o arquivo para outra coisa. Eu diria que o UTF8 deve fazê-lo. Deixe-nos saber como foi.
Marian

Respostas:

8

A partir dos comentários, o problema não está exatamente na tabela ou na maneira como o SQLCMD importa os caracteres especiais. Geralmente, importações problemáticas estão relacionadas ao formato do próprio script.

O próprio Management Studio oferece a opção de salvar com uma codificação específica, que deve resolver o problema no futuro. Ao salvar um arquivo pela primeira vez (ou use salvar como), clique na pequena seta próxima ao botão Salvar , para usar a opção Salvar com codificação .

insira a descrição da imagem aqui

Por padrão, ele salva o arquivo na Europa Ocidental (1252) . Sempre que tenho caracteres especiais, uso UTF8 (embora talvez alguma outra codificação restritiva se encaixe) porque geralmente é a correção mais rápida.

insira a descrição da imagem aqui

Não tenho certeza (da foto) de que você está usando SSMS; portanto, verifique se o seu próprio editor tem a opção de salvar o arquivo em uma codificação diferente. Caso contrário, a conversão do arquivo em um editor inteligente (como você já tentou no Notepad ++) geralmente funciona. Embora isso possa não funcionar se você estiver convertendo de uma codificação ampla para uma mais estreita e depois voltar para uma ampla (por exemplo: de Unicode para ANSI e de volta para Unicode).

Marian
fonte
Oi Marian. Mais uma vez obrigado. Usei o recurso 'Transferência de dados' da Navicat, porque gosto da maneira como ele gera o script sql (rápido, independente de arquivos mdf e desde agora sempre funcionou para mim). Verifiquei alguns parâmetros no recurso 'Transferência de dados' da Navicat, mas não encontrei nenhuma maneira de alterar a codificação do arquivo de saída. Vou ter que fazer um trabalho extra usando o Notepad ++ para alterar a codificação, mas não é grande coisa.
Oskytar
Bem, não há problema. Embora, normalmente, as agradecimentos neste site sejam entregues usando o recurso Upvote (a seta para cima próxima à resposta) se a resposta for útil ou, se resolver seu problema completamente, mesmo usando a marca como resposta (a marca de seleção próxima à resposta ) :-). Veja mais aqui, no FAQ .
Marian
Corrijo meu último comentário: É possível escolher a codificação de saída do arquivo ao executar 'Transferência de dados' com o Navicat.
Oskytar
Legal, agora você poderá ignorar a etapa de conversão manual. Isso é ainda melhor.
Marian
2
Esta resposta parece não estar correta. Eu tinha o arquivo salvo pelo Notepad ++ no UTF-8. SQLCMD.exe não transfere os caracteres corretamente. Se eu copiar o conteúdo para o SSMS, ele funcionará bem. A solução real foi a resposta fornecida pelo swasheck para adicionar param -f 65001.
Tomas Kubes
39

Outra opção, uma que eu só aprendi, vem a sqlcmddocumentação . Você precisa definir a página de código para sqlcmdcorresponder à da codificação do arquivo. No caso de UTF-8, a página de códigos é 65001, então você deseja:

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

swasheck
fonte
1
Isso acabou de salvar minha vida, eu estava prestes a fazer um script do PowerShell para ler um arquivo CSV com o import-csv-codifying UTF8 para corrigir isso. Obrigado
Spörri
Isso funcionou para mim quando tive que inserir valores de texto em irlandês com fadas (á, é, í, ó, ú) em uma coluna NVARCHAR
meio-
Esta é a resposta correta
Pitchmatt
2

Esse tipo de coisa é muito complicado, porque muito é feito sem contar a você.

A primeira coisa que eu faria é usar o sqlcmd para exibir a string. Se ele for exibido corretamente na janela do cmd.exe, esse é um fato útil. Em seguida, selecionaria a linha convertda string para varbinary para ver quais bytes estão realmente lá. Acho que a cartografía aparecerá como 0x636172746f67726166c3ad61, onde o "i" acentuado é representado pelos bytes c3ad, que é a codificação UTF-8 para esse caractere. Não é bom ter UTF-8 em uma coluna em espanhol moderno (Windows 1252). O valor de byte no Windows 1252 para esse caractere é 237 decimal (hex ED).

Se a coluna contiver dados codificados incorretamente, o erro está na forma como foram inseridos. Talvez a remoção do N principal nas constantes da string - N'string'diga ao SQL Server para gerar uma string Unicode, mas simples 'string'indica que os caracteres usam a codificação do cliente - inserindo o espanhol moderno em vez do Unicode.

Se a coluna contiver dados codificados corretamente, eu diria que você encontrou um bug na exibição da GUI.

Se você não conseguir que o sqlcmd insira os dados corretamente (N inicial ou não), você deverá reclamar com a Microsoft. Ao fazê-lo, ser capaz de mostrar os bytes armazenados na coluna - usando convert(colname as varbinary)- será fundamental para explicar o que está acontecendo de errado.

James K. Lowden
fonte
Olá James, muito obrigado pela sua resposta detalhada. Fiz alguns testes e o Sqlcmd.exe não está mostrando a seqüência correta. É claramente um problema sobre como os dados são inseridos.
Oskytar
Usando o Sql Profiler, depurei quais sentenças foram enviadas para o SQL SERVER ao usar o cliente SQl Server GUI. INSERT INTO [ElementType] ([Código], [Nome], [Descrição], [GeometryType], [stringId], [CapturedGeometryType]) VALORES ('ESTACION', 'Estación', 'Estación', 'Multiponto', NULL, 'Ponto'); funcionou muito bem, então todos os sotaques foram inseridos corretamente! Essa é a mesma 'frase de inserção' que aparece no meu script sql. Devo especificar o código do caractere no arquivo de script sql?
Oskytar