Re: 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.  
> 

Agreed

> 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 saw. Perhaps the confusion is caused by SQLGetInfo that mix server
informations with driver ones.
I'll write a test to check what happen changing isolation level during
connection, after connection and using implicit transactions in odbc.
 
> 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?  
> 

I always agreed with this, I'll update either transaction setting or
SQLGetInfo.

> 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?  
> 


I don't know. Many options require additional code to check values or
update dependency attributes. Also SQLGetInfo returns different
informations so only SQLSetStmtAttr/SQLGetStmtAttr and
SQLSetConnectAttr/SQLGetConnectAttr would share code.... however I think
it's worth considering it.

freddy77