Bug 990339 - mysql-connector-odbc/unixODBC interaction can lose SQL_ATTR_AUTOCOMMIT
mysql-connector-odbc/unixODBC interaction can lose SQL_ATTR_AUTOCOMMIT
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: unixODBC (Show other bugs)
19
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Jan Staněk
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-30 22:17 EDT by Andy Lutomirski
Modified: 2014-01-07 02:22 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-07 02:22:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andy Lutomirski 2013-07-30 22:17:59 EDT
[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.)
Comment 1 Andy Lutomirski 2013-07-31 17:25:34 EDT
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.)
Comment 2 Honza Horak 2013-08-12 11:03:43 EDT
Thanks for reporting, we'll backport that fix.
Comment 3 Fedora Admin XMLRPC Client 2013-09-11 10:22:00 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Jan Staněk 2013-10-22 03:51:06 EDT
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?
Comment 5 Andy Lutomirski 2013-12-19 15:33:45 EST
Sorry for the ridiculous delay here.  unixODBC-2.3.2-2.fc20.x86_64 appears to be okay.
Comment 6 Jan Staněk 2014-01-07 02:22:26 EST
Thanks for the confirmation.

Note You need to log in before you can comment on or make changes to this bug.