ig has asked for the wisdom of the Perl Monks concerning the following question:
The Jade ODBC driver provided with Greentree ERP system does not support the autocommit option and, therefore, DBI refuses to connect. I tried Win32::ODBC but that crashed. It works fine from Access and vbscript but I would like to be able to use it from perl.
Does anyone have experience or a solution for accessing Greentree data from perl or using any ODBC driver that is read-only and does not support autocommit?
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: ODBC without autocommit
by mje (Curate) on Oct 09, 2009 at 08:17 UTC | |
What happens when you call DBI->connect? What errors do you get back? | [reply] |
by ig (Vicar) on Oct 09, 2009 at 22:39 UTC | |
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. | [reply] |
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] |
by ig (Vicar) on Oct 12, 2009 at 20:57 UTC | |
by mje (Curate) on Oct 12, 2009 at 22:37 UTC | |
|
Re: ODBC without autocommit
by Anonymous Monk on Oct 09, 2009 at 08:34 UTC | |
| [reply] |
by mje (Curate) on Oct 09, 2009 at 08:49 UTC | |
That won't necessarily help if his driver does not support the auto commit connection attribute as DBD::ODBC will still call SQLSetConnectAttr. We need to see the error. | [reply] |
by ig (Vicar) on Oct 09, 2009 at 23:07 UTC | |
Here's a level 15 trace:
The output to STDERR:
And the test script
DBD::ODBC attempts to set autocommit unconditionally (i.e. it does so even if the autocommit option is set to false) and even if it doesn't, DBI itself does so. Preventing the specific instances is easy (I have done it and the connect works) but more work would be required to make the effect optional. I am reasonably certain (but would be happy to be surprised) that the current code does not provide any option to avoid setting this option or to ignore failures setting it. | [reply] [d/l] [select] |
by mje (Curate) on Oct 12, 2009 at 08:17 UTC | |