Поделиться через

Указания по программированию

  • Статья

Скачать драйвер ODBC

Функции программирования драйвера Microsoft ODBC для SQL Server в macOS и Linux основаны на ODBC в sql Server Native Client (SQL Server Native Client (ODBC)). Собственный клиент SQL Server основан на ODBC в компонентах доступа к данным Windows (справочник программиста ODBC).

Приложение ODBC может использовать несколько активных результирующих наборов (MARS) и другие функции SQL Server, включая /usr/local/include/msodbcsql.h заголовки unixODBC (sql.h, sqlext.h, sqltypes.hи sqlucode.h). Затем используйте те же символьные имена для элементов SQL Server, которые будут использоваться в приложениях Windows ODBC.

Доступные компоненты

В следующих разделах документации по sql Server Native Client для ODBC (SQL Server Native Client (ODBC)) допустимы при использовании драйвера ODBC в macOS и Linux:

Неподдерживаемые функции

Правильность работы следующих функций в этой версии драйвера ODBC не была проверена на платформах macOS и Linux:

Следующие функции недоступны в версии драйвера ODBC для платформ macOS и Linux:

  • Распределенные транзакции (атрибут SQL_ATTR_ENLIST_IN_DTC не поддерживается).
  • Зеркальное отображение базы данных
  • FILESTREAM
  • Производительность драйвера ODBC, описанная в SQLSetConnectAttr, и следующие атрибуты подключения, связанные с производительностью:
    • SQL_COPT_SS_PERF_DATA
    • SQL_COPT_SS_PERF_DATA_LOG
    • SQL_COPT_SS_PERF_DATA_LOG_NOW
    • SQL_COPT_SS_PERF_QUERY
    • SQL_COPT_SS_PERF_QUERY_INTERVAL
    • SQL_COPT_SS_PERF_QUERY_LOG
  • SQLBrowseConnect (до версии 17.2)
  • Типы интервалов C, такие как SQL_C_INTERVAL_YEAR_TO_MONTH (задокументированы в статье Идентификаторы и дескрипторы типов данных)
  • Значение SQL_CUR_USE_ODBC атрибута SQL_ATTR_ODBC_CURSORS функции SQLSetConnectAttr.

Поддержка кодировок

Для версий 13 и 13.1 драйвера ODBC данные SQLCHAR должны иметь кодировку UTF-8. Другие кодировки не поддерживаются.

Для версии 17 драйвера ODBC поддерживаются данные SQLCHAR в одной из следующих кодировок:

Примечание.

Из-за iconv различий в musl и glibc многие из этих языковых стандартов не поддерживаются в Alpine Linux.

Дополнительные сведения см. в статье Functional differences from glibc (Функциональные различия с glibc).

Имя Описание
UTF-8 Unicode
CP437 Латиница MS-DOS (США)
CP850 Латиница 1 MS-DOS
CP874 Латиница/тайский
CP932 Японский, Shift-JIS
CP936 Китайский (упрощенный), GBK
CP949 Корейский, EUC-KR
CP950 Китайский (традиционный), Big5
CP1251 Кириллица
CP1253 Греческий
CP1256 Арабский
CP1257 Балтийская
CP1258 Вьетнамский
ISO-8859-1 / CP1252 Латиница-1
ISO-8859-2 / CP1250 Латиница-2
ISO-8859-3 Латиница-3
ISO-8859-4 Латиница-4
ISO-8859-5 Латиница/кириллица
ISO-8859-6 Латиница/арабский
ISO-8859-7 Латиница/греческий
ISO-8859-8 / CP1255 Иврит
ISO-8859-9 / CP1254 Турецкий
ISO-8859-13 Латиница-7
ISO-8859-15 Латиница-9

При подключении драйвер определяет текущий языковой стандарт процесса, в котором он загружен. Если используется одна из перечисленных выше кодировок, драйвер применяет ее для данных SQLCHAR (узкий набор символов). В противном случае по умолчанию применяется кодировка UTF-8. Так как все процессы по умолчанию запускаются с языковым стандартом "C" (из-за чего драйвер по умолчанию использует кодировку UTF-8), если приложению необходимо использовать одну из перечисленных выше кодировок, перед подключением в нем нужно задать соответствующий языковой стандарт с помощью функции setlocale. При этом нужный языковой стандарт необходимо указать либо явным образом, либо с помощью пустой строки, например setlocale(LC_ALL, ""), чтобы использовался языковой стандарт среды.

В обычной среде Linux или macOS применяется кодировка UTF-8, и в этом случае после обновления драйвера ODBC с версии 13 или 13.1 до версии 17 пользователи не заметят разницы. Однако если приложение использует отличную от UTF-8 кодировку из приведенного выше списка с помощью функции setlocale(), оно должно применять ее для данных, передаваемых в драйвер и из него, вместо UTF-8.

Данные SQLWCHAR должны иметь кодировку UTF-16LE (прямой порядок байтов).

При привязке входных параметров с помощью SQLBindParameter, если указан узкий тип SQL, например SQL_VARCHAR, драйвер преобразует предоставленные данные из кодирования клиента в кодировку SQL Server по умолчанию (обычно кодовая страница 1252). Выходные параметры драйвер преобразует из кодировки, указанной в сведениях о параметрах сортировки, связанных с данными, в кодировку клиента. Однако возможна потеря данных — символы исходной кодировки, не имеющие соответствия в конечной кодировке, преобразуются в вопросительные знаки (?).

Чтобы избежать этого при привязке входных параметров, укажите символьный тип Юникода SQL, например SQL_NVARCHAR. В этом случае драйвер выполняет преобразование из кодировки клиента в кодировку UTF-16, в которой могут быть представлены все символы Юникода. Кроме того, конечный столбец или параметр на сервере также должен иметь тип Юникода (nchar, nvarchar, ntext) или такой тип, в параметрах сортировки или кодировке которого могут быть представлены все символы исходных данных. Чтобы избежать потери данных в выходных параметрах, укажите для Юникода тип SQL либо тип C (SQL_C_WCHAR), вследствие чего драйвер вернет данные в кодировке UTF-16 либо в узкосимвольном типе C, и убедитесь в том, что в кодировке клиента могут быть представлены все символы исходных данных (это представление всегда возможно в случае с UTF-8).

Дополнительные сведения о параметрах сортировки и кодирования см. в разделе Поддержка параметров сортировки и Юникода.

Существуют различия в преобразовании кодировки между Windows и рядом версий библиотеки iconv в Linux и macOS. Текстовые данные в кодовой странице 1255 (иврит) имеют одну кодовую точку (0xCA), которая ведет себя по-разному при преобразовании в Юникод. В Windows этот символ преобразуется в кодовую точку UTF-16 0x05BA. В macOS и Linux с библиотекой libiconv до версии 1.15 он преобразуется в кодовую точку 0x00CA. В Linux с библиотеками iconv, которые не поддерживают редакцию 2003 кодировки Big5/CP950 (BIG5-2003), добавленные с использованием этой редакции символы преобразуются неправильно. В кодовой странице 932 (японский, Shift-JIS) результат декодирования символов, которые изначально не определены в стандарте кодировки, также различается. Например, байт 0x80 преобразуется в U+0080 в Windows, но может стать U+30FB в Linux и macOS в зависимости от версии iconv.

Когда в ODBC Driver 13 и 13.1 многобайтовые символы UTF-8 или суррогаты UTF-16 распределяются между буферами SQLPutData, это приводит к повреждению данных. Для потоковой передачи SQLPutData используйте буферы, чтобы не разделять на части кодировку одного символа. В версии 17 драйвера ODBC это ограничение снято.

OpenSSL

Начиная с версии 17.4, драйвер загружает OpenSSL динамически, что позволяет запускать его на системах, имеющих версию 1.0, либо 1.1, без надобности в отдельных файлах драйверов. Начиная с версии 17.9, драйвер поддерживает OpenSSL 3.0 в дополнение к предыдущим версиям. При наличии нескольких версий OpenSSL драйвер пытается загрузить последнюю версию.

Версия драйвера Поддерживаемые версии OpenSSL
17.4 и выше 1.0, 1.1
17.9, 18.0 или более поздние версии 1.0, 1.1, 3.0

Примечание.

При этом возможен конфликт, если приложение, использующее драйвер (или один из его компонентов), связано с другой версией OpenSSL или динамически загружает ее. Если в системе присутствует несколько версий OpenSSL и приложение используют их, настоятельно рекомендуется убедится, что версии, загруженные приложением и драйвером, совпадают, так как ошибки могут привести к повреждению памяти и, таким образом, они не обязательно будут проявляться очевидным или последовательным образом.

Alpine Linux

На момент написания этой статьи размер стека по умолчанию в MUSL составляет 128 КБ, что достаточно для основных функций драйвера ODBC, но это ограничение можно легко увеличить, если потребуется для приложения, особенно при вызове драйвера из нескольких потоков. Для увеличения размера стека мы рекомендуем компилировать приложение ODBC в Alpine Linux с -Wl,-z,stack-size=<VALUE IN BYTES>. Для сведения, размер стека по умолчанию в большинстве систем GLIBC составляет 2 МБ.

Дополнительные замечания

  • Вы можете сделать подключение к выделенному администратору (DAC) с помощью проверки подлинности SQL Server и узла, порта. Члену роли Sysadmin сначала нужно сначала обнаружить порт выделенного административного соединения. Инструкции см. в статье Диагностическое соединение для администраторов баз данных. Например, если бы порт выделенного административного соединения имел значение 33000, вы могли бы подключиться к нему с помощью sqlcmd следующим образом:

    sqlcmd -U <user> -P <pwd> -S <host>,33000

    Примечание.

    Подключения DAC должны использовать проверку подлинности SQL Server.

  • Диспетчер драйверов UnixODBC возвращает ошибку "Недопустимый идентификатор атрибута или параметра" для всех атрибутов инструкции, когда они передаются через SQLSetConnectAttr. Когда SQLSetConnectAttr в среде Windows получает значение атрибута инструкции, он передает это значение драйверу для установки во всех активных инструкциях, являющихся дочерними элементами дескриптора подключения.

  • При использовании драйвера с очень многопоточными приложениями проверка обработки unixODBC может стать узким местом производительности. Вы можете увеличить производительность в таких сценариях, выполнив компиляцию unixODBC с параметром --enable-fastvalidate. Однако следует помнить, что в этом случае вместо ошибок SQL_INVALID_HANDLE будет происходить аварийное завершение работы приложений, которые передают в ODBC API некорректные дескрипторы.

См. также

Вопросы и ответы
Известные проблемы в данной версии драйвера
Заметки о выпуске