다음을 통해 공유

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

ODBC 드라이버 다운로드

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

Known issues

추가 문제는 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)을 호출할 때 이 변환을 시도하지 않습니다.

  • ColumnSize 매개 변수 SQLBindParameter 는 SQL 형식의 문자 수를 참조하는 반면 BufferLength는 애플리케이션 버퍼의 바이트 수입니다. 그러나 SQL 데이터 형식이 varchar(n) 또는 char(n)인 경우 애플리케이션은 C 형식 또는 SQL_C_CHAR SQL 형식에 대해 매개 변수 SQL_CHAR 를 바인딩하고 SQL_VARCHAR 클라이언트의 문자 인코딩이 UTF-8인 경우 String data, right truncation 값이 서버의 데이터 형식 크기에 맞춰지더라도 드라이버에서 오류가 발생할 수 있습니다. 이 오류는 문자 인코딩 간의 변환으로 데이터의 길이가 변경될 수 있으므로 발생합니다. 예를 들어 오른쪽 아포스트로피 문자(U+2019)는 CP-1252에서 싱글 바이트로 0x92인코딩되지만 UTF-8은 3 바이트 시퀀스 0xE2 0x80 0x99로 인코딩됩니다.

예를 들어 인코딩이 UTF-8이고 Out 매개 변수에 대해 BufferLength 및 ColumnSize 모두에 SQLBindParameter 대해 1을 지정한 다음 서버의 열에 저장된 char(1) 이전 문자를 검색하려고 하면(CP-1252 사용) 드라이버는 3바이트 UTF-8 인코딩으로 변환하려고 시도하지만 결과를 1바이트 버퍼에 맞출 수 없습니다. 다른 방향에서는 클라이언트와 서버의 다른 코드 페이지 간에 변환을 수행하기 전에 ColumnSize 와 BufferLengthSQLBindParameter 를 비교합니다. 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 이하에서 다음 오류가 발생합니다.

[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은 일반적으로 Homebrew를 통해 설치되며 , 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

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

Related content