다음을 통해 공유

Linux 및 macOS 기반 ODBC 드라이버의 알려진 문제

  • 아티클

ODBC 드라이버 다운로드

이 문서에는 Linux 및 macOS 기반 Microsoft ODBC Driver 13, 13.1, 17 및 18 for SQL Server를 사용하는 경우 알려진 문제 목록이 포함되어 있습니다. 연결 문제를 해결하는 단계도 제공됩니다.

알려진 문제

추가적인 문제는 SQL Server 드라이버 블로그에 게시됩니다.

  • 시스템 라이브러리의 제한으로 인해 Alpine Linux는 더 적은 수의 문자 인코딩과 로캘을 지원합니다. 예를 들어 en_US.UTF-8은 사용할 수 없습니다. 자세한 내용은 musl libc - glibc의 기능 차이점을 참조하세요.

  • Windows, Linux 및 macOS는 PUA(프라이빗 사용 영역) 또는 EUDC(최종 사용자 정의)의 문자를 다르게 변환할 수 있습니다. Transact-SQL 내에서 서버에 수행되는 변환은 Windows 변환 라이브러리를 사용합니다. 드라이버의 변환은 Windows, Linux 또는 macOS 변환 라이브러리를 사용합니다. 각 라이브러리는 이러한 변환을 수행할 때 서로 다른 결과를 생성할 수 있습니다. 자세한 내용은 최종 사용자 정의 및 프라이빗 사용 영역 문자를 참조하세요.

  • 클라이언트 인코딩이 UTF-8인 경우 드라이버 관리자가 항상 UTF-8에서 UTF-16으로 올바르게 변환하는 것은 아닙니다. 현재, 문자열에서 1개 이상의 문자가 유효한 UTF-8 문자가 아닌 경우 데이터 손상이 발생합니다. ASCII 문자가 올바르게 매핑됩니다. ODBC API의 SQLCHAR 버전(예: SQLDriverConnectA)을 호출할 때 드라이버 관리자가 이 변환을 시도합니다. ODBC API의 SQLWCHAR 버전(예: SQLDriverConnectW)을 호출할 때 드라이버 관리자가 이 변환을 시도하지 않습니다.

  • SQLBindParameter의 ColumnSize 매개 변수는 SQL 유형의 문자 수를 나타내며, BufferLength는 애플리케이션 버퍼의 바이트 수를 나타냅니다. 그러나 SQL 데이터 형식이 varchar(n) 또는 char(n)이고, 애플리케이션이 매개 변수를 C 형식의 경우 SQL_C_CHAR로, SQL 형식의 경우 SQL_CHAR 또는 SQL_VARCHAR로 바인딩하고 클라이언트의 문자 인코딩이 UTF-8인 경우, ColumnSize의 값이 서버에서 데이터 형식의 크기와 정렬되는 경우에도 드라이버에서 "문자열 데이터의 오른쪽이 잘렸습니다"라는 오류를 받을 수 있습니다. 이 오류는 문자 인코딩 간 변환으로 인해 데이터 길이가 변경될 수 있기 때문에 발생합니다. 예를 들어 오른쪽 아포스트로피 문자(U+2019)는 CP-1252에서 1바이트 0x92로 인코딩되지만, UTF-8에서는 3바이트 시퀀스 0xe2 0x80 0x99로 인코딩됩니다.

예를 들어 사용하는 인코딩이 UTF-8인데 출력 매개 변수의 SQLBindParameter에서 BufferLength 및 ColumnSize에 모두 1을 지정한 다음, 서버에서 char(1) 열에 저장된 앞의 문자를 CP-1252를 사용하여 검색하려고 시도하면 드라이버에서 해당 문자를 3바이트 UTF-8 인코딩으로 변환하지만 결과를 1바이트 버퍼에 맞출 수 없습니다. 다른 방향에서는 클라이언트와 서버의 서로 다른 코드 페이지 간에 변환을 수행하기 전에 ColumnSize를 SQLBindParameter의 BufferLength와 비교합니다. ColumnSize가 1이면 (예를 들어) BufferLength가 3보다 작기 때문에 드라이버가 오류를 생성합니다. 이 오류를 방지하려면 변환 후의 길이가 지정된 버퍼 또는 열에 맞는지 확인합니다. ColumnSize는 varchar(n) 형식에서 8000보다 클 수 없습니다.

연결 문제 해결

ODBC 드라이버를 사용하여 SQL Server에 연결할 수 없는 경우 다음 정보를 활용하여 문제를 확인합니다.

가장 일반적인 연결 문제는 UnixODBC 드라이버 관리자의 복사본이 두 개 설치되는 것입니다. libodbc*.so*에 대해 /usr을 검색합니다. 파일 버전이 2개 이상 표시되면 드라이버 관리자가 2개 이상 설치되어 있을 가능성이 높습니다. 애플리케이션이 잘못된 버전을 사용할 수 있습니다.

다음 항목이 포함된 다음 섹션이 포함되도록 /etc/odbcinst.ini 파일을 편집하여 연결 로그를 활성화합니다.

[ODBC]
Trace = Yes
TraceFile = (path to log file, or /dev/stdout to output directly to the terminal)

다른 연결 오류가 발생하고 로그 파일이 표시되지 않으면 컴퓨터에 드라이버 관리자의 복사본이 두 개 있을 수 있습니다. 그러지 않으면 로그 출력은 다음과 유사하게 표시됩니다.

[ODBC][28783][1321576347.077780][SQLDriverConnectW.c][290]
        Entry:
            Connection = 0x17c858e0
            Window Hdl = (nil)
            Str In = [DRIVER={ODBC Driver 18 for SQL Server};SERVER={contoso.com};Trusted_Connection={YES};WSID={mydb.contoso.com};AP...][length = 139 (SQL_NTS)]
            Str Out = (nil)
            Str Out Max = 0
            Str Out Ptr = (nil)
            Completion = 0
        UNICODE Using encoding ASCII 'UTF8' and UNICODE 'UTF16LE'

예를 들어 ASCII 문자 인코딩이 UTF-8이 아닌 경우 다음과 같습니다.

UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

설치된 드라이버 관리자가 둘 이상이면 애플리케이션에서 잘못된 드라이버 관리자를 사용 중이거나 드라이버 관리자가 올바르게 빌드되지 않은 것입니다.

일부 macOS 사용자에게는 드라이버 버전 17.8 이하에서 다음 오류가 발생합니다.
(이 오류는 드라이버 버전 17.9 이상에서 해결되었습니다.)

[08001][Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: [OpenSSL library could not be loaded, make sure OpenSSL 1.0 or 1.1 is installed]
[08001][Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection (0) (SQLDriverConnect)

OpenSSL 3.0이 설치된 경우 이 오류가 발생할 수 있습니다. OpenSSL은 일반적으로 Brew를 통해 설치되며 openssl, openssl@1.1, openssl@3 이진 파일을 포함합니다.

이 오류를 해결하려면 openssl 이진 파일의 symlink를 openssl@1.1로 변경합니다.

rm -rf $(brew --prefix)/opt/openssl
version=$(ls $(brew --prefix)/Cellar/openssl@1.1 | grep "1.1")
ln -s $(brew --prefix)/Cellar/openssl@1.1/$version $(brew --prefix)/opt/openssl

연결 오류 해결에 대한 자세한 내용은 다음을 참조하세요.

다음 단계

ODBC 드라이버 설치 지침은 다음 문서를 참조하세요.

자세한 내용은 프로그래밍 지침 및 릴리스 정보를 참조하세요.