Re^2: ODBC without autocommit

With trace on DBD::ODBC aborts the connect when the attempt to set autocommit on fails.

post_connect/SQLSetConnectAttr(SQL_AUTOCOMMIT)

This is from dbdimp.c in DBD::ODBC. If I comment this out, and a bit of DBI.pm that also attempts to set autocommit, then the connection completes and I can read data. The comment in dbdimp.c where autocommit is set says: DBI spec requires AutoCommit on, and comments in DBI concur. It is, unfortunately, not easy to change them because, unless they parse and understand the SQL they submit to the server, they can't distinguish what changes the database (needing a transaction and where autocommit is relevant) from what only reads the database, particularly in the case of stored procedures. I may try to find a way that a connect option prevents all attempts to set autocommit, but still I would have hacked versions of DBI and DBD::ODBC, so I'm hoping there is some other existing solution.

Comment on Re^2: ODBC without autocommit

Replies are listed 'Best First'.
Re^3: ODBC without autocommit by mje (Curate) on Oct 12, 2009 at 08:16 UTC
There is no solution to this that I know of that does not involve changing DBD::ODBC or changing the ODBC Driver. If it is important to you then the best way would be to add a DBD::ODBC connect attribute which either ignores HYC000 errors or disables all calls to set the commit attribute (the latter is probably better). However, this would also need to trap someone specifically calling begin_work, commit, rollback. I am happy to accept such a patch from you which you could post in rt.cpan.org.	[reply]
Re^4: ODBC without autocommit by ig (Vicar) on Oct 12, 2009 at 20:57 UTC
I am able to access the data with a combination of `Win32::OLE` and the `ADODB.Connection` object. While it is easy enough to patch DBD::ODBC so as not to get or set the SQL_AUTOCOMMIT option it is more difficult to deal with the assumptions in DBI regarding this option. I have successfully tested a crude hack but I don't think it is worth pursuing, given that Win32::OLE is working. Thanks for considering the issue and confirming my conclusion, and the offer to accept a patch. I'll keep it in mind, in case I run into more read-only drivers.	[reply] [d/l] [select]
Re^5: ODBC without autocommit by mje (Curate) on Oct 12, 2009 at 22:37 UTC
I am sorry to hear you are not prepared to pursue this but also not surprised if you have found another solution which does the job. Although the error message is "optional feature not implemented" you appear to have found one of only 2 ODBC drivers I have come across in over 10 years which do not support setting/getting the autocommit attribute. I don't think it would be that great an issue to patch DBD::ODBC to ignore autocommit but have never had the impetus to do this since until now I've only come across one driver (out of dozens) it would benefit. I have no experience with WIN32::OLE so cannot comment on any advantages of disadvantages (other than the one you have found) but I wish you the best of luck. If, for any reason you come back to DBD::ODBC let me know at my cpan address and I might be prepared to look at this myself. At present, it appears to be a niche requirement.	[reply]