Bug 990339

Summary: mysql-connector-odbc/unixODBC interaction can lose SQL_ATTR_AUTOCOMMIT
Product: [Fedora] Fedora Reporter: Andy Lutomirski <luto>
Component: unixODBCAssignee: Jan Staněk <jstanek>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 19CC: databases-maint, hhorak
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-07 07:22:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andy Lutomirski 2013-07-31 02:17:59 UTC
[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 21:25:34 UTC
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 15:03:43 UTC
Thanks for reporting, we'll backport that fix.

Comment 3 Fedora Admin XMLRPC Client 2013-09-11 14:22:00 UTC
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 07:51:06 UTC
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 20:33:45 UTC
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 07:22:26 UTC
Thanks for the confirmation.