Bug #89365 for DBD-ODBC: t/02simple.t failure on Debian with mysql ODBC driver

Wed Oct 09 08:10:45 2013 MICHIELB [...] cpan.org - Ticket created

Subject:

t/02simple.t failure on Debian with mysql ODBC driver

Hi, I installed libmyodbc in debian from the repositories. The t/02simple.t test fails on DBD::ODBC, latest version from CPAN, and also when run on the git master branch. contents of /etc/odbcinst.ini [MySQL] Description = ODBC for MySQL Driver = /usr/lib/i386-linux-gnu/odbc/libmyodbc.so Setup = /usr/lib/i386-linux-gnu/odbc/libodbcmyS.so FileUsage = 1 # Perl 5.14.2 # osname=linux, osvers=2.6.32-5-686-bigmem, archname=i486-linux-gnu-thread-multi-64int # Using DBI 1.622 # Using DBD::ODBC 1.44_3 # Using DBMS_NAME 'MySQL' # Using DBMS_VER '5.5.31-0+wheezy1' # Using DRIVER_NAME 'libmyodbc5.so' # Using DRIVER_VER '05.01.0010' # odbc_has_unicode 0 DBI_DSN=dbi:ODBC:DRIVER={MySQL};Server=localhost;Port=3306;Database=test # Failed test 'ReadOnly set' # at t/02simple.t line 57. # got: '0' # expected: '1' # Looks like you failed 1 test of 66. t/02simple.t ................. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/66 subtests (less 3 skipped subtests: 62 okay)

Wed Oct 09 08:33:27 2013 bohica [...] ntlworld.com - Correspondence added

On Wed Oct 09 08:10:45 2013, MICHIELB wrote: Show quoted text

> Hi, > > I installed libmyodbc in debian from the repositories. > The t/02simple.t test fails on DBD::ODBC, latest version from CPAN, > and also when run on the git master branch. > > contents of /etc/odbcinst.ini > > [MySQL] > Description = ODBC for MySQL > Driver = /usr/lib/i386-linux-gnu/odbc/libmyodbc.so > Setup = /usr/lib/i386-linux-gnu/odbc/libodbcmyS.so > FileUsage = 1 > > # Perl 5.14.2 > # osname=linux, osvers=2.6.32-5-686-bigmem, archname=i486-linux-gnu- > thread-multi-64int > # Using DBI 1.622 > # Using DBD::ODBC 1.44_3 > # Using DBMS_NAME 'MySQL' > # Using DBMS_VER '5.5.31-0+wheezy1' > # Using DRIVER_NAME 'libmyodbc5.so' > # Using DRIVER_VER '05.01.0010' > # odbc_has_unicode 0 > > DBI_DSN=dbi:ODBC:DRIVER={MySQL};Server=localhost;Port=3306;Database=test > > # Failed test 'ReadOnly set' > # at t/02simple.t line 57. > # got: '0' > # expected: '1' > # Looks like you failed 1 test of 66. > t/02simple.t ................. Dubious, test returned 1 (wstat 256, > 0x100) > Failed 1/66 subtests > (less 3 skipped subtests: 62 okay)

The problem here is DBD::ODBC calls SQLSetConnectAttr to set SQL_ACCESS_MODE and when it asks for it back it is not what it was set to. It is possibly the same issue as with SQLite in that it may be the ODBC driver says it doesn't do SQL_ACCESS_MODE and although DBD::ODBC can detect this and issue a warning the warning will never be seen because of https://rt.cpan.org/Ticket/Display.html?id=89015 in DBI. However, it could just as easily be a bug in the MySQL driver. I cannot tell without seeing what the call to SQLSetConnectAttr returns. If it is SQL_SUCCESS_WITH_INFO it does not handle it and can be added to the SQLite list thus waiting for DBI fix (which I personally, haven't quite got to grips with yet). If you are prepared to do a unixODBC log to tell me which of the above it is you do this: Edit /etc/odbcinst.ini and the top of this file add something like: [ODBC] Trace=yes TraceFile=/tmp/unixodbc.log Now just run the 02simple test with something like: prove -vb t/02simple.t Now edit /etc/odbcinst.ini to change the Yes to a No (or logging will slow down ODBC from now on). Look in /tmp/unixodbc.log for SQL_ACCESS_MODE string and paste around 20 or lines before and after it here. Martin -- Martin J. Evans Wetherby, UK

Wed Oct 09 08:33:27 2013 The RT System itself - Status changed from 'new' to 'open'

Wed Oct 09 08:45:59 2013 MICHIELB [...] cpan.org - Correspondence added

attached the test & log output. t/02simple.t .. 1..66 ok 1 - use DBI; ok 2 - use ODBCTEST; # # Perl 5.19.4 # osname=linux, osvers=3.2.0-4-686-pae, archname=i686-linux # Using DBI 1.628 # Using DBD::ODBC 1.44_3 # Using DBMS_NAME 'MySQL' # Using DBMS_VER '5.5.31-0+wheezy1' # Using DRIVER_NAME 'libmyodbc5.so' # Using DRIVER_VER '05.01.0010' # odbc_has_unicode 0 not ok 3 - ReadOnly set # Failed test 'ReadOnly set' # at t/02simple.t line 57. # got: '0' # expected: '1' ok 4 - ReadOnly cleared

Subject:

unixodbc.log

Message body is not shown because it is too large.

Wed Oct 09 08:58:57 2013 bohica [...] ntlworld.com - Correspondence added

On Wed Oct 09 08:45:59 2013, MICHIELB wrote: Show quoted text

> attached the test & log output. > > t/02simple.t .. > 1..66 > ok 1 - use DBI; > ok 2 - use ODBCTEST; > # > # Perl 5.19.4 > # osname=linux, osvers=3.2.0-4-686-pae, archname=i686-linux > # Using DBI 1.628 > # Using DBD::ODBC 1.44_3 > # Using DBMS_NAME 'MySQL' > # Using DBMS_VER '5.5.31-0+wheezy1' > # Using DRIVER_NAME 'libmyodbc5.so' > # Using DRIVER_VER '05.01.0010' > # odbc_has_unicode 0 > not ok 3 - ReadOnly set > > # Failed test 'ReadOnly set' > # at t/02simple.t line 57. > # got: '0' > # expected: '1' > ok 4 - ReadOnly cleared

In this case: [ODBC][10959][1381322599.058070][SQLSetConnectAttr.c][321] Entry: Connection = 0x9766b98 Attribute = SQL_ATTR_ACCESS_MODE Value = 0x1 StrLen = -5 [ODBC][10959][1381322599.058101][SQLSetConnectAttr.c][675] Exit:[SQL_SUCCESS] <--- NOTE success [ODBC][10959][1381322599.058148][SQLGetConnectAttr.c][285] Entry: Connection = 0x9766b98 Attribute = SQL_ATTR_ACCESS_MODE Value = 0xbf910c14 Buffer Length = -5 StrLen = (nil) [ODBC][10959][1381322599.058176][SQLGetConnectAttr.c][757] Exit:[SQL_SUCCESS] but value coming back was not 1 - so ODBC driver broken. Chalk this one down to an ODBC driver issue. It can return SQL_SUCCESS_WITH_INFO and option value changed (i.e., it does not do it) or SQL_SUCCESS and it should return the value previous set. Martin -- Martin J. Evans Wetherby, UK

Thu Oct 31 05:04:02 2013 bohica [...] ntlworld.com - Correspondence added

On Wed Oct 09 08:58:57 2013, MJEVANS wrote: Show quoted text

> On Wed Oct 09 08:45:59 2013, MICHIELB wrote:

> > attached the test & log output. > > > > t/02simple.t .. > > 1..66 > > ok 1 - use DBI; > > ok 2 - use ODBCTEST; > > # > > # Perl 5.19.4 > > # osname=linux, osvers=3.2.0-4-686-pae, archname=i686-linux > > # Using DBI 1.628 > > # Using DBD::ODBC 1.44_3 > > # Using DBMS_NAME 'MySQL' > > # Using DBMS_VER '5.5.31-0+wheezy1' > > # Using DRIVER_NAME 'libmyodbc5.so' > > # Using DRIVER_VER '05.01.0010' > > # odbc_has_unicode 0 > > not ok 3 - ReadOnly set > > > > # Failed test 'ReadOnly set' > > # at t/02simple.t line 57. > > # got: '0' > > # expected: '1' > > ok 4 - ReadOnly cleared

> > In this case: > > [ODBC][10959][1381322599.058070][SQLSetConnectAttr.c][321] > Entry: > Connection = 0x9766b98 > Attribute = SQL_ATTR_ACCESS_MODE > Value = 0x1 > StrLen = -5 > [ODBC][10959][1381322599.058101][SQLSetConnectAttr.c][675] > Exit:[SQL_SUCCESS] <--- NOTE success > [ODBC][10959][1381322599.058148][SQLGetConnectAttr.c][285] > Entry: > Connection = 0x9766b98 > Attribute = SQL_ATTR_ACCESS_MODE > Value = 0xbf910c14 > Buffer Length = -5 > StrLen = (nil) > [ODBC][10959][1381322599.058176][SQLGetConnectAttr.c][757] > Exit:[SQL_SUCCESS] > > but value coming back was not 1 - so ODBC driver broken. > > Chalk this one down to an ODBC driver issue. It can return > SQL_SUCCESS_WITH_INFO and option value changed (i.e., it does not do > it) or SQL_SUCCESS and it should return the value previous set. > > Martin

I should have worked around this one in v 1.45 now. After discussion on dbi-dev and irc it was suggested that drivers which return SQL_SUCCCESS_WITH_INFO and option value changed should just cause DBD::ODBC to act like readonly is set and return that value if asked. DBD::ODBC also issues a warning in this case but you need the most recent DBI release to get that. I closing this now but by all means reopen if you find I'm wrong. Martin -- Martin J. Evans Wetherby, UK

Thu Oct 31 05:04:03 2013 bohica [...] ntlworld.com - Status changed from 'open' to 'resolved'

Thu Oct 31 05:04:03 2013 bohica [...] ntlworld.com - Fixed in 1.45 added

Thu Oct 31 11:00:52 2013 bohica [...] ntlworld.com - Correspondence added

Just to clear up this rt and re discussion on irc. The problem with mysql was not the same as sqlite (which I originally guessed it was and hence why I wrote this rt off with that explantion). In mysql's case it looks like a straight forward bug that if you set SQL_ACCESS_MODE to 1 then read it back again it is 0 and the setting returned SQL_SUCCESS not SQL_SUCCESS_WITH_INFO, option value changed. Martin -- Martin J. Evans Wetherby, UK