Команда SQLCMD не може вставити наголоси

Я намагаюся запустити sqlcmd.exe для встановлення нової бази даних з командного рядка. Я використовую SQL SERVER Express 2012 у Windows 7 64 біт.

Ось команда, яку я використовую:

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

Ось фрагмент сценарію створення файлу 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'

Ну, будь ласка, перевірте, чи є наголоси на словах; що є описом таблиці. База даних створюється без проблем. "Співставити" розуміють сценарій, як ви бачите на доданому скріншоті. Незважаючи на це, при вивченні таблиці наголоси не відображаються належним чином.

Я дуже вдячний за будь-яку допомогу. Велике спасибі.

[Редагувати]: Привіт усім. Зміна кодування файлів SQL за допомогою Notepad ++ працювала чудово! Дуже дякую за допомогу: я дізнався щось цікаве з цією проблемою!

Що стосується коментарів, проблема полягає не в тому, що саме з таблицею чи способом SQLCMD імпортує спеціальні символи. Зазвичай проблемний імпорт пов'язаний з форматом самого сценарію.

Сама студія управління пропонує можливість збереження за допомогою конкретного кодування, що повинно вирішити проблему в майбутньому. Під час першого збереження файлу (або використання зберегти як) слід натиснути на маленьку стрілку біля кнопки « Зберегти », щоб скористатися опцією « Зберегти за допомогою кодування» .

За замовчуванням він зберігає файл у західноєвропейській (1252) . Щоразу, коли у мене є якісь спеціальні символи, я використовую UTF8 (хоча, можливо, підійде якесь інше обмежувальне кодування), оскільки це, як правило, найшвидше виправити.

Я не впевнений (на малюнку), що ви використовуєте SSMS, тому переконайтесь, що ваш власний редактор має можливість зберегти файл у іншому кодуванні. Якщо ні, то конвертування файлу в розумному редакторі (як ви вже пробували в Notepad ++), як правило, працює. Хоча це може не спрацювати, якщо ви перетворюєте з широкого кодування в більш вузьке, а потім повертаєтеся до широкого (наприклад: з Unicode в ANSI і назад в Unicode).

Ще один варіант, який я тільки що дізнався, походить до sqlcmdдокументації . Вам потрібно встановити сторінку коду, sqlcmdщоб вона відповідала кодуванню файлу. У випадку UTF-8 кодова сторінка становить 65001, тому вам потрібно:

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

Такі речі дуже складні, тому що стільки робиться, не розповідаючи.

Перше, що я б зробив, це використовувати sqlcmd для відображення рядка. Якщо воно вірно відображається у вікні cmd.exe, це один корисний факт. Далі я б convertобрав рядок з рядком у varbinary, щоб побачити, які байти є насправді. Я думаю картографія відобразиться як 0x636172746f67726166c3ad61, де наголошене "i" представлено байтами c3ad, що кодує UTF-8 для цього символу. Недоцільно мати UTF-8 у колоні сучасної іспанської мови (Windows 1252). Значення байту в Windows 1252 для цього символу становить 237 десятків (шестнадцятковий ED).

Якщо стовпець містить неправильно кодовані дані, то помилка полягає в тому, як він був вставлений. Можливо, видалення провідних N у константах рядка -N'string' говорить SQL Server, щоб генерувати рядок Unicode, але просте 'string'вказує, що символи використовують кодування клієнта - вставив би сучасну іспанську мову замість Unicode.

Якщо стовпець містить правильно закодовані дані, то я б сказав, що ви знайшли помилку на дисплеї GUI.

Якщо ви не можете отримати sqlcmd, щоб правильно вставити дані (ведучі N чи ні), ви хочете подати скаргу в Microsoft. Коли ви це зробите, можливість відображення байтів як збережених у стовпці - використовуючи convert(colname as varbinary)- буде вирішальним для пояснення того, що відбувається не так.