supported ODBC attributes

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