Re^3: ODBC without autocommit

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.

Comment on Re^3: ODBC without autocommit

Replies are listed 'Best First'.
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]