[To be fair, this isn't actually a mysql-connector-odbc bug; it's a unixODBC bug. It appears to be triggered by a recent change in mysql-connector-odbc, though.] On older Fedora versions (F17 and, I think, F18), libmyodbc.so exports SQLSetConnectAttr. On F19 it does not. This causes a bug that makes the CHECK_SQLSETCONNECTATTR check in do_attr in unixODBC's SQLConnect.c return false and do_attr to therefore have no effect. (I'm not entirely sure which piece of unixODBC code should be considered buggy, but something is definitely buggy.) This causes a severe problem in code like this: SQLSetConnectAttr(hdbc_, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_OFF, 0); SQLDriverConnect(hdbc_, NULL, (unsigned char *)conn_str_.c_str(), SQL_NTS, NULL, 0, NULL, SQL_DRIVER_NOPROMPT); if (!SQL_SUCCEEDED(ret)) throw SqlError("Failed to connect", GetODBCDiags(hdbc_, SQL_HANDLE_DBC)); unixODBC cleverly defers the autocommit setting until connected (I have no idea why), but it isn't applied after connection either. So autocommit gets left on and data is lost. (Fortunately my test suite caught this.)
This should probably be reassigned to unixODBC: http://mailman.unixodbc.org/pipermail/unixodbc-dev/2013-July/001775.html (The upstream patch is in the tarball but hasn't made it to svn AFAICS.)
Thanks for reporting, we'll backport that fix.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I recently updated unixODBC to the latest upstream tarball, which should include the aforementioned fix. Could you please test it with # yum --enablerepo=updates-testing update unixODBC and then running your code?
Sorry for the ridiculous delay here. unixODBC-2.3.2-2.fc20.x86_64 appears to be okay.
Thanks for the confirmation.