Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article contains a list of known issues with the Microsoft ODBC Driver 13, 13.1, 17, and 18 for SQL Server on Linux and macOS. It also contains steps for troubleshooting connectivity issues.
Known issues
For additional issues, see the SQL Server Drivers blog.
Due to system library limitations, Alpine Linux supports fewer character encodings and locales. For example,
en_US.UTF-8
isn't available. For more information, seemusl libc
- functional differences fromglibc
.Windows, Linux, and macOS convert characters from the Private Use Area (PUA) or End User-Defined Characters (EUDC) differently. Conversions performed on the server within Transact-SQL use the Windows conversion library. Conversions in the driver use the Windows, Linux, or macOS conversion libraries. Each library can produce different results when performing these conversions. For more information, see End-User-Defined and Private Use Area Characters.
If the client encoding is UTF-8, the driver manager doesn't always correctly convert from UTF-8 to UTF-16. Currently, data corruption occurs when one or more characters in the string aren't valid UTF-8 characters. ASCII characters are mapped correctly. The driver manager attempts this conversion when calling the SQLCHAR versions of the ODBC API (for example, SQLDriverConnectA). The driver manager doesn't attempt this conversion when calling the SQLWCHAR versions of the ODBC API (for example, SQLDriverConnectW).
The ColumnSize parameter of
SQLBindParameter
refers to the number of characters in the SQL type, while BufferLength is the number of bytes in the application's buffer. However, if the SQL data type is varchar(n) or char(n), the application binds the parameter asSQL_C_CHAR
for the C type, andSQL_CHAR
orSQL_VARCHAR
for the SQL type, and the character encoding of the client is UTF-8, you might get aString data, right truncation
error from the driver even if the value of ColumnSize is aligned with the size of the data type on the server. This error occurs since conversions between character encodings can change the length of the data. For example, a right apostrophe character (U+2019
) is encoded in CP-1252 as the single-byte0x92
, but in UTF-8 as the 3-byte sequence0xE2 0x80 0x99
.
For example, if your encoding is UTF-8 and you specify 1 for both BufferLength and ColumnSize in SQLBindParameter
for an out-parameter, and then attempt to retrieve the preceding character stored in a char(1)
column on the server (using CP-1252), the driver attempts to convert it to the 3-byte UTF-8 encoding, but can't fit the result into a 1-byte buffer. In the other direction, it compares ColumnSize with the BufferLength in SQLBindParameter
before doing the conversion between the different code pages on the client and server. Because a ColumnSize of 1 is less than a BufferLength of (for example) 3, the driver generates an error. To avoid this error, ensure that the length of the data after conversion fits into the specified buffer or column. ColumnSize can't be greater than 8000 for the varchar(n)
type.
Troubleshoot connection problems
If you're unable to make a connection to SQL Server using the ODBC driver, use the following information to identify the problem.
The most common connection problem is to have two copies of the UnixODBC driver manager installed. Search /usr for libodbc*.so*. If you see more than one version of the file, you (possibly) have more than one driver manager installed. Your application might use the wrong version.
Enable the connection log by editing your /etc/odbcinst.ini
file, to contain the following section with these items:
[ODBC]
Trace = Yes
TraceFile = (path to log file, or /dev/stdout to output directly to the terminal)
If you get another connection failure and don't see a log file, there (possibly) are two copies of the driver manager on your computer. Otherwise, the log output should be similar to:
[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'
If the ASCII character encoding isn't UTF-8, for example:
UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'
There's more than one driver manager installed, and your application is using the wrong one, or the driver manager wasn't built correctly.
Some macOS users encounter the following error with driver version 17.8 or older:
[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)
The error can happen when OpenSSL 3.0 is installed. OpenSSL typically is installed through Homebrew, and it contains the openssl
, [email protected]
, and openssl@3
binaries.
To resolve this error, change the symlink of the OpenSSL binary to [email protected]
:
rm -rf $(brew --prefix)/opt/openssl
version=$(ls $(brew --prefix)/Cellar/[email protected] | grep "1.1")
ln -s $(brew --prefix)/Cellar/[email protected]/$version $(brew --prefix)/opt/openssl
Related tasks
For more information about resolving connection failures, see:
- Steps to troubleshoot SQL connectivity issues
- SQL Server 2005 Connectivity Issue Troubleshoot - Part I
- Connectivity troubleshooting in SQL Server 2008 with the Connectivity Ring Buffer
- SQL Server Authentication Troubleshooter