Dean, I somehow missed the thread you refer to.
ODBC does support asynchronous mode and the following summary may help: Asynchrous mode is controlled using the connection or statement level attribute SQL_ATTR_ASYNC_ENABLE - which may be set to SQL_ASYNC_ENABLE_OFF or SQL_ASYNC_ENABLE_ON. Drivers may support statement level asynchronous execution of connection level asynchrous execution (you ascertain this by calling SQLGetInfo for SQL_ASYNC_MODE which may return SQL_AM_CONNECTION, SQL_AM_STATEMENT for statement or SQL_AM_NONE for not supported. If a driver is SQL_ASYNC_CONNECTION then either all statements are synchronous or all are asynchronous (and setting SQL_ATTR_ASYNC_ENABLE on a statement will return an error). If SQL_AM_STATEMENT you can mix synchronous and asynchronous statements. When in asynchronous mode some functions will return immediately with SQL_STILL_EXECUTING and you call it repeatedly until it returns a success or error state. Also you can only call SQLGetDiagRec, SQLGetDiagField, SQLCancel and the original function (the one that returned SQL_STILL_EXECUTING) on a statement or those functions and SQLAllocHandle on a connection. Functions can be called on other statements. SQLCancel cancels the processing on a statement. Asynchronous mode in ODBC is really only for OSs which don't support threads and that is even the recommendation in the spec. See the spec for what functions can be called asynchronously. I know of only one application that makes use of asynchronous mode in ODBC and it is an ODBC 1.0 application. As for DBD::ODBC odbc_async_exec does enable asynchronous mode (if the driver returns SQL_AM_STATEMENT) but it was added as a way of obtaining messages from procedures rather than supporting full asynchronous mode. i.e. When DBD::ODBC turns asynchronous mode on it loops on any function returning SQL_STILL_EXECUTING attempting to retrieve any diagnostics each loop. It does not return back to DBI. I think there is a test in the test suite which does this. Martin -- Martin J. Evans Easysoft Ltd, UK Development On 05-Aug-2005 Dean Arnold wrote: > Since I'm going to need to implement some support > for it in DBIx::Threaded soon, I thought I'd stir up the > hornets nest (tho only briefly). > > After reviewing this thread: > > http://www.mail-archive.com/[email protected]/msg03408.html > > and skimming thru the more common DBDs on CPAN, > can I conclude that only DBD::ODBC and DBD::Teradata provides any > driver level support for async execution at this point ? > (is odbc_async_exec() really async ? Looks more like an > intermediate msg dispatcher to me...) > > When I implement support for *true* async capability in > DBIx::Threaded (primarily so I can externally abort in-progress > executions), I'd hope to make it usable by any other > drivers that wish to implement async operation. > > And while I've got your attention, here's my current list of > drivers that support multistatement requests with a > more_results() type i/f: > > DBD::ODBC > DBD::DB2 > DBD::Sybase > DBD::Teradata > > Are there others ? > > TIA, > Dean Arnold > Presicient Corp.
