Skip to Content.
Sympa Menu

freetds - [freetds] supported ODBC attributes

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: TDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: [freetds] supported ODBC attributes
  • Date: Thu, 6 Mar 2008 00:46:24 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page