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.

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.

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.