FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Hi Freddy, 

I'd like to construct a list similar to api_status.txt for ODBC connection
attributes.  There are so many attributes, and our support for them isn't
100%.  It would be much kinder to the user to offer a quick reference to
what he can fairly expect.  

The fellow who maintains the OTL library wrote to me because our ODBC
driver faked him out: 

    status=SQLSetConnectAttr
    (hdbc,
     SQL_ATTR_TXN_ISOLATION,
     ...

SQLGetInfo says the driver supports all isolation levels:

        case SQL_TXN_ISOLATION_OPTION:
                /* TODO check SQLSetConnectAttr support */
                UIVAL = SQL_TXN_READ_COMMITTED | SQL_TXN_READ_UNCOMMITTED |
SQL_TXN_REPEATABLE_READ | SQL_TXN_SERIALIZABLE;

SQLGetConnectAttr/SQLSetConnectAttr report success for all those, and it's
faithfully stored in dbc->attr.txn_isolation.  

Trouble is, txn_isolation is never used.  :-(

I think it's very bad to say, Yes we support Feature XYZ, and let the user
get and set the value, but just plain ignore it.  A driver is free to say
what it supports in SQLGetInfo.  Could we work toward making its answers a
little more accurate?  

While I'm at it, a gratuitous design suggestion.  Perhaps instead of long
switch statements for setting attributes, we could devise a table,
something like this:

typedef void (*action) (TDS_DBC *dbc);
struct {
        int offset;
        SQLINT  attribute;
        attribute_type  type; /* pointer, integer enum */
        SQLINT *domain;
        action  jackson;
} connection_attributes[] = { /* ... */ };

We would need only a little code to verify that a passed-in value is valid
(in the domain array) and to assign the value to the proper offset in the
TDS_DBC structure, and call the appropriate function.  

Such a table could be shared between SQLGetInfo, SQLGetConnectAttr, and
SQLSetConnectAttr.  I can see a lot of advantages for truth-telling.  What
do you think?  

Regards, 

--jkl