Почему тире становится вопросом? Или проблемы с кодированием данных на SQL

Обратился ко мне клиент, которому я полгода назад делала загрузку данных из Excel в список продукции Заявки от клиента. Видео по результату.
Файл формировался в Китае, где не используется привычная нам кириллица.

Загружается товар с таким названием «ABM3C‐25‐D4Y‐T».

Получаем в списке после загрузки «ABM3C?25?D4Y?T».Через ProFiler отловила процедуру записи:

exec 3, 'ABM3C‐25‐D4Y‐T'

То есть замена происходит уже на самом SQL. База данных создана на платформе Клиент Коммуникатор. По привычке проверила параметры сортировки у самой базы данных, всё хорошо — Cyrillic_General_CI_AS, как и рекомендовано при установке.

Поигралась с cast и convert — выдает вопросы вместо тире. Решить проблему самостоятельно не получилось… Обратилась в службу технической поддержки разработчика платформы Клиент Коммуникатор с данной проблемой.

Ответ разработчика сначала сильно удивил: «Надо использовать тип данных Nvarchar, а у Вас видимо используется Varchar». Запись ведется в поле с типом данных nvarchar (ставится по умолчанию при создании поля в конфигураторе).

Показываю, что самый простой скрипт выдает мне всё те же злополучные знаки вопроса.
select 'ABM3C‐25‐D4Y‐T', cast('ABM3C‐25‐D4Y‐T' as nvarchar)

Получила совет — перед первой одинарной кавычкой поставить N.

select N'ABM3C‐25‐D4Y‐T'

выдал мне желаемый результат. Добавив N, мы указали SQL, что обрабатывать данную строку надо как значение в Unicode.

Исправила вызов процедуры, добавив N:

exec 3, N'ABM3C‐25‐D4Y‐T'

Всегда знала, что надо ставить букву N перед кавычкой, но не придавала этому особого значения, пока не столкнулась с данной проблемой.