All pages
Powered by GitBook
1 of 1

Loading...

Connector/ODBC 2.0.19 Changelog

The most recent Stable (GA) release of MariaDB Connector/ODBC is:MariaDB Connector/ODBC 3.2.5

DownloadRelease NotesChangelogAbout MariaDB Connector/ODBC

Release date: 5 Jun 2019

For the highlights of this release, see the release notes.

The revision number links will take you to the revision's page on GitHub. On GitHub you can view more details of the revision and view diffs of the code modified in that revision.

  • Revision #d42d88f 2019-05-27 18:06:30 +0200

    • Merge of latest 3.0 changes(3.0.7-3.0.9) into 2.0

  • 2019-05-02 20:21:24 +0200

    • The fix and the testcase

      • Also fixed precision, octet length, and display size calculation in case of unsigned decimal field and/or 0 scale.

  • 2019-04-26 00:12:16 +0200

    • The fix and updated testcases

      • The driver treated NULL values as empty strings when checked if the SQLTables call is special case for the databases list return.

      • Also contains fixes for and

  • 2019-04-09 00:47:36 +0200

    • Added FORCETLS connection string option

      • This is for implementation of the C/C MYSQL_OPT_SSL_ENFORCE option, which enables forcing TLS use

  • 2019-04-08 15:30:40 +0200

    • Changed mysql_options calls as it's deprecated

  • 2019-04-04 19:28:45 +0200

    • Version bump -> 3.0.9

  • 2019-03-23 16:30:52 +0100

    • Making sure SSL options are not empty strings and not white spaces only. That shouldn't normally happen, as the connector trims dsn field values, and does not store empty strings. But better to be safe.

  • 2019-03-21 23:18:47 +0100

    • The fix and the testcase

      • This bug boils down to a crash in SQLGetData if an application unbinds result buffers after execution, i.e. calls SQLFreeStmt(SQL_UNBIND). That happened because SQL_UNBIND freed columns metadata along with freeing bind buffers.

  • 2019-03-21 15:36:41 +0100

    • Added connection string option TLSVERSION

      • This option can be used to enforce MARIADB_OPT_TLS_VERSION C/C option to limit allowed for the connection TLS versions.

      • The value can be either a bitmap, where bit 1 corresponds to TLSv1.1, bit 2 - TLSv1.2, and 4 - to TLSv1.3, or it can be set as combination of string names TLSv1.1, TLSv1.2 and TLSv1.3.

  • 2019-03-19 22:13:05 +0100

    • Added option for reading section in my.cnf

      • Connection string option is USE_MYCNF. OPTIONS bit 65536 may also be used.

      • The checkbox for the option has been added to Windows setup dialog. Removed some garbage from rc file along the way. Test of the option has been added to connstring.

  • 2019-03-18 14:57:46 +0100

    • The fix only - not new tests needed

      • will enable tests for this bug

  • 2019-03-17 23:25:49 +0100

    • The fix and the testcase.

      • The bug is actually in SSIS. It binds column size as signed int, but the value for LONGTEXT is max unsigned int. Connector was returning truncation error on the row fetch. And that is probably not quite right. The patch makes connector not to return truncation error in case if truncation is caused solely by sign-ness of the field/buffer.

  • 2019-03-14 21:20:01 +0100

    • The fix of the build in travis with latest C/C release

  • 2019-03-13 20:55:57 +0100

    • The fix and the testcase.

      • This bug boils down to not reporting correct columns count in case of a query with multiple results(stored procedure or statements batch) if the result with affected rows count followed a resultset.

      • In case of stored procedure(like in the bug report) this is always the case, if SP returns a result set.

  • 2019-02-28 23:41:21 +0100

    • The fix and the testcase.

      • Connector returned wrong value for SQL_DESC_FIXED_PREC_SCALE. In the report it was going about bigint type, but in fact for many other types SQL_TRUE was returned, where it shouldn't be. Since definition of SQL_DESC_FIXED_PREC_SCALE is not clear, we checked what SQL Server driver returns for different types for reference. Only for (small)money types SQL_TRUE is returned. For types that has counterparts in MariaDB, SQL_FALSE is always returned. Thus, SQL_FALSE has been made a default value for all types for the SQL_DESC_FIXED_PREC_SCALE field.

  • 2019-01-24 15:54:55 +0100

    • Fix of error made in tests framework by previous commit

  • 2019-01-23 21:28:59 +0100

    • The fix and the testcase

      • SQL_DESC_PARAMETER_TYPE was returned in wrong type - integer instead of small integer. Also, application could get it not only from Ipd descriptor, but also from Ird.

  • 2018-12-20 16:42:02 -0700

    • Fix multi-statement param realloc. Example use case: Prepare the following SQL statement: "INSERT INTO tbl (a,b) VALUES (?,?); SELECT 1 FROM tbl WHERE c = ?" First execution of prepared statement will work, second execution will segfault or cause memory corruption.

  • 2019-01-03 19:15:48 +0100

    • Merge branch 'master' into .0

  • 2018-10-17 12:39:33 +0100

    • Add SQL_OUTER_JOINS support to SQLGetInfo This is an older attribute that is largely superseded by the newer SQL_OJ_CAPABILITIES attribute but some software checks it first and only uses SQL_OJ_CAPABILITIES to get more details if SQL_OUTER_JOINS says they are supported.

  • 2019-01-02 13:31:26 +0100

    • Updating libmariadb to the 3.0.8 release tag

  • 2018-12-10 18:16:41 +0100

    • The patch moves string to date/time types conversion from C/C on C/ODBC side to better meet ODBC requirements.

  • 2018-12-02 22:31:37 +0100

    • The fix and the testcase. The problem occurred only with data fetched as SQL_C_WCHAR. That happened because for statement handles after 1st one, there wasn't STMT_ATTR_UPDATE_MAX_LENGTH attribute set, and getting data as a widestring depends on max_length.

  • 2018-11-30 01:16:37 +0100

    • SQLGetData did not return empty wide string

  • 2018-11-28 01:33:13 +0100

    • odbc*.ini files were generated in CMAKE_SOURCE_DIR, instead of CMAKE_BINARY_DIR. That probably is not right, and they have to be along with tests binaries

  • 2018-11-16 12:06:49 +0100

    • The new logo in README.md

  • 2018-11-13 00:01:24 +0100

    • The fix of one compilation warning and of the memory leak introduced by one of fixes in this release

  • 2018-11-09 01:07:26 +0100

    • , and fixes These are all date/time types related issues. Correct errors, fractional part, type conversions.(overflow errors detection and reporting) was partly done earlier. is mostly fix in C/C, but added similar changes to similar function in c/odbc, and added the testcase.

  • 2018-11-05 23:44:43 +0100

    • and - fixes and testcases Connector would not return NULL for 0000-00-00 datetime values in case of SQLGetData call, while doing that in SQLFetch. Also it would not do that in case of empty string conversion to date/time types. If time field fetched as timestamp type, fractional part is set to 0. The patch makes SQLFetch and SQLGetData to use the same function to copy data to application buffers and process erroneous values.

  • 2018-10-31 15:13:35 +0100

    • The fix and the testcase + test The problem was incorrect buffer address calculation for the TIMESTAMP type in case of row-based columns binding. That caused the error in ADO, and could cause a crash. Some issues were fixed along the way. Like caring of the case when value buffer is not provided for the field, or if Indicator and StrLen (for the column) have different buffers.

  • 2018-10-18 00:52:16 +0200

    • The fix and testcases The main issue was incorrect processing of the connect string with NULL-separated key=value pairs. But also there were found and fixed many issues with ConfigDSN use. Like no dialogs/message boxes should be showed if the parent window handle isn't provided. Extended dsn_test to test ConfigDSN more thoroughly in the interactive mode.

  • 2018-10-13 00:03:03 +0200

    • Improved the SQLProcedureColumns testcase It would fail if connection charset was not a single-byte

  • 2018-10-10 00:43:37 +0200

    • Removing C/C auth plugins from packages

  • 2018-10-03 00:41:59 +0200

    • Last part. Caring of 0-date in the string Enforcing of the constraint on date/time values in case they are passed as a string. Enhanced the testcase for Fixed calculation of the SQL type from the concise type - it didn't consider ODBCv3 types.

  • 2018-10-01 14:31:21 +0200

    • The fix and the testcase The fix has been accidentally lost in previous commit. In case if SQL_DATA_TYPE value was fetched in the bound buffer, the truncation error would occur. The fix is casting the column in the query to SIGNED type

  • 2018-09-20 15:58:05 +0200

    • The fix and testcases This is fixes several issues with SQLColumns and SQLProcedureColumns, as they share good part of SQL queries. Most of issues are rather minor.

  • 2018-09-18 17:58:38 +0200

    • Change requested in - SQL_DATA_TYPE value casted to SIGNED in SQLColumns query. Otherwise its type(returned by server) is MEDIUM_BLOB. Even though at the moment it's not quite clear what is the problem, the change looks reasonable.

  • 2018-09-13 17:48:26 +0200

    • The fix and the testcase. If data was fetched using SQLGetData, with batches of SELECTS that would fail like described int the bug - empty values or even the program crash. The reason was that in such case one of structures involved in the data fetching was not reset on move to the new resultset. Also the patch fixes SQLRowsCount for batches of upserts or other statements generating affected rows count

  • 2018-09-12 11:34:19 +0200

    • The fix and the testcase If SQL_TIME field was bound as SQL_C_TIMESTAMP, and the day field was not zero, the inserted time value would be different from the value in time fields of the parameter(server would add total number of hours in those days to the time). The patch makes connector to copy only time fields for the parameter. Also, the patch enforces time and date validity checks for such parameters, as the specs require.

  • 2018-09-12 11:34:19 +0200

    • The fix and the testcase

  • 2018-09-11 20:17:54 +0200

    • The fix + the testcase The crash or error could be caused by error in the (client side) query parsing in case of a dash followed by a string containing newline character and semicolon

  • 2018-09-10 14:41:08 +0200

    • Version bump -> 2.0.19

  • Checkbox group has been added to the Windows setup dialog. If no checkbox is checked there means all versions are allowed.

  • The testcase tests only correct connection string parsing/storing

  • The file win/ma_odbc_setup.h has been moved to 'dsn' directory, as there was already the file with the same name, that wasn't used. 'win' directory has been removed, since that was the only file there

  • The bug occured becaule IRD was not reset in the SQLMoreResults in the described case.

  • Fixed mistake in previous commit(for ODBC-216) - lost statement handler reinitialization in one place.

  • Revision #832360f
    ODBC-211
    Revision #38e4205
    ODBC-225
    ODBC-245
    ODBC-246
    Revision #1e633f8
    ODBC-238
    Revision #9d1d94b
    ODBC-239
    Revision #3b39fe0
    Revision #031e0ac
    Revision #fb0ac79
    ODBC-232
    Revision #172c399
    ODBC-228
    Revision #21864d5
    ODBC-229
    Revision #1aad919
    ODBC-234
    ODBC-233
    Revision #553c71f
    ODBC-231
    Revision #5165a90
    Revision #35f9e5d
    ODBC-219
    Revision #8d22a84
    ODBC-216
    Revision #aaba291
    Revision #646803f
    ODBC-213
    Revision #7b463c1
    ODBC-207
    Revision #99a8ac0
    ODBC-3
    Revision #5d5ec8e
    Revision #5916978
    Revision #cb5b7ce
    ODBC-205
    Revision #20e0a50
    ODBC-203
    Revision #f1e0cd2
    ODBC-204
    Revision #92699ab
    Revision #07381cc
    Revision #3eed852
    Revision #a94af40
    ODBC-43
    ODBC-198
    ODBC-199
    ODBC-43
    ODBC-198
    Revision #ae8467a
    ODBC-194
    ODBC-197
    Revision #351c1aa
    ODBC-192
    ODBC-194
    Revision #1e3184f
    ODBC-188
    Revision #63fcf15
    ODBC-186
    Revision #9ed4a7a
    ODBC-190
    Revision #bc32db6
    ODBC-70
    ODBC-70
    Revision #d49df3d
    ODBC-152
    Revision #fa081fb
    ODBC-186
    Revision #a9e55d1
    ODBC-152
    Revision #bfb78c0
    ODBC-169
    Revision #79efd0e
    ODBC-182
    Revision #79efd0e
    ODBC-182
    Revision #548db71
    ODBC-181
    Revision #21f200a

    This page is: Copyright © 2025 MariaDB. All rights reserved.