Skip to Content.
Sympa Menu

freetds - Re: [freetds] supported ODBC attributes

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] supported ODBC attributes
  • Date: Thu, 6 Mar 2008 15:23:35 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page