Ошибка ODBC SQL Server в Юникоде?

0

Задний план:

У нас есть приложение, которое использует ODBC API для взаимодействия с Access и SQL Server (динамически, в зависимости от конфигурации пользователя).

Я обнаружил ошибку, которая может быть в драйвере SQL ODBC, или может быть проблемой неправильной конфигурации с созданным нами ODBC DSN или может быть как-то ошибкой в нашем коде.

Когда документ редактируется и сохраняется, мы запрашиваем базу данных, чтобы узнать, имеет ли этот файл соответствующую запись в базе данных - если это так, мы обновляем запись с обновленными данными из документа; если нет, мы делаем вставку для создания необходимой записи для нее.

Мы используем имя файла как уникальный первичный ключ в нашей таблице, и это нормально работает нормально. Ошибка заключается в том, что если имя файла содержит символы за пределами текущей кодовой страницы ANSI, то выбор указывает на отсутствие совпадений:

   SQL:  SELECT * FROM "My Designs" WHERE "PATHNAME" = '\\FILE-SERVER\Home Folders\User Files\狭すぎて丸め処理が出来ません!!.foo'   [# matches = 0]

Однако, когда попытка вставки пыталась, мы получаем уникальное нарушение ключа (конечно) - так как уже есть запись с этим именем файла.

Database error: Violation of PRIMARY KEY constraint 'PK__My Desig__1B3D5B4BF643706B'. Cannot insert duplicate key in object 'dbo.My Designs'. The duplicate key value is (\\FILE-SERVER\Home Folders\User Files\狭すぎて丸め処理が出来ません!!.foo).
The statement has been terminated.

Я был над кодом с тонкой зубной гребенкой, и я не вижу ничего плохого. :(

Сгенерированный оператор SQL выводит правильный выход Unicode имени файла. Наше приложение скомпилировано для Unicode. Столбец SQL_WVARCHAR в ODBC говорят.

Я попытался добавить AutoTranslate=no в строку конфигурации DSN, но это, похоже, не имеет никакого эффекта.

Я попытался подключиться к базе данных с панели управления ODBC. К сожалению, этот интерфейс создает файл журнала ANSI - поэтому я не могу проверить проблемы UNICODE/ANSI с помощью этого инструмента.

Вопросов:

  • Есть ли инструмент, который я могу использовать для проверки того, что эти операторы создаются/выдаются корректно драйвером ODBC в базу данных SQL Server?
  • Существует ли лучший способ использовать ODBC, чтобы драйвер не получал пустую строку UNICODE в запросе SELECT или запросе INSERT?
  • Любые другие идеи о том, как подойти к этой проблеме (без замены нашей технологии)
  • 0
    Вы пробовали свою команду в SQL Server Management Studio? Это первое, что вы должны сделать, чтобы убедиться, что вы не теряете время, полагая, что это проблема ODBC.
  • 0
    @PaulMcKenzie - Использование SQL SMS не работает лучше. Действительно, тот же запрос дает 0 результатов, но тот, который содержит символы только в текущей кодовой странице, дает действительные результаты. Есть идеи?
Показать ещё 5 комментариев
Теги:
sql-server
odbc
mfc
unicode

1 ответ

1
Лучший ответ

В инструкции select убедитесь, что вы заключили строку where where с N, чтобы указать SQL в unicode:

..."PATHNAME" = N'\\FILE-SERVER\Home Folders\User Files\狭すぎて丸め処理が出来ません!!.foo'

Кроме того, MFC преобразует данные в MCBS или UNICODE в зависимости от вашей конфигурации. Убедитесь, что вы используете CStringT в наборе записей.

  • 0
    Спасибо - пытаюсь заставить это работать сейчас. Синтаксис N'string 'терпит неудачу в MS Access (я чувствую, что, должно быть, я делаю что-то не так в ODBC, что этот тип не обрабатывается драйвером?) Я буду повышать / отмечать как ответ, если смогу получить это работает :)

Ещё вопросы

Сообщество Overcoder
Наверх
Меню