Chris Waterson wrote:
You probably already know this, but...the problem is that the "connection" doesn't really have anything to do with supporting transactions in MySQL; the storage engine that backs a particular table does. A single connection can interact with tables that are backed by a variety of different storage engines. In fact, you can mix tables from different storage engines in a single *statement*.
... for which you have my complete sympathies ;-)
It is possible for me to detect when a ROLLBACK has been issued against a non-transactional table. In this case, I could raise an error; however, doing this would be different behavior than the ODBC driver. (Besides being too late for the programmer to do anything about it!) But perhaps this is preferable?
To be sure, what happens in the ODBC case depends on what the user puts in odbc.ini. The user can indicate for either the full-on error treatment, or the ignoring the problem for non-transactional tables. In any case, you and the MySQL user community are probably in a better position to determine what is the most sensible course of action here too. If you feel that the HDBC API needs to become more rich, I'm quite happy to entertain suggestions there too.
o Non-ASCIIText - OK for now, but MySQL has significant support for Unicode and encodings, so that should be on the to-do list.
There has been recent work in the PostgreSQL backend that could perhaps be a constructive example. -- John