Changes in MySQL Connector/ODBC 8.0.31 (2022-10-11, General Availability)

• Security Notes

• Functionality Added or Changed

• Bugs Fixed

Security Notes

• For platforms on which Connector/ODBC utilizes MySQL Server's bundled OpenSSL library (MacOS, Windows, and GenLinux), MySQL Server's linked OpenSSL library was updated to version 1.1.1q. Issues fixed in the new OpenSSL version are described at https://www.openssl.org/news/cl111.txt and https://www.openssl.org/news/vulnerabilities.html. (Bug #34414691)

Functionality Added or Changed

• Packaging: On Windows, the debugging (PDB) files were moved to a separate download. While the regular packages are built with RelWithDebInfo enabled, the associated PDB files are no longer included in the standard downloads. The separate debug package contains PDB files for the regular builds (in lib/), driver files and their associated PDB files built in Debug mode (in Debug/lib/), and unit tests. (WL #15124)

• Removed the deprecated NO_I_S connection option; usage is ignored and does not trigger an error or warning. (WL #15150)

• Added the ssl-crl and ssl-crlpath connection options to configure the Certificate Revocation List (CRL) list. (WL #14880)

Bugs Fixed

• Converting binary data to binhex with SQLGetData() would unexpectedly halt on the 2nd call to SQLGetData() when the buffer size was smaller than the data size. (Bug #34486645)

• Now the connection collation can now be specified via INITSTMT; when before setting it was overridden by the ODBC driver. (Bug #34020457)

• With the ANSI ODBC driver, a call to SQLColumns returned the Unicode DATA_TYPE equivalent; SQL_WVARCHAR instead of SQL_VARCHAR, SQL_WCHAR instead of SQL_CHAR, and SQL_WLONGVARCHAR instead of SQL_LONGVARCHAR. (Bug #107766, Bug #34355094)

• Improved query parameter support and performance with prepared statements. (Bug #107745, Bug #34350417)

• Added a test case for a Server bug that was fixed in MySQL Server 8.0.31; its release note is as follows:

  A prepared statement with parameters could fail to update a row, but the same statement with the same data did update the row when issued as a query. The fix for the problem is to assign a default data type to the parameters, although this can be inefficient because there is no context available for data type propagation and a character string type is given implicitly. In this case, the best practice is to wrap such parameter declarations in CAST clauses that supply the desired data types. (Bug #105013, Bug #33401384)