[freetds] FreeTDS, unixODBC, and libodbc++

Joel Apter japter at ibxtech.com
Thu Jun 12 15:14:47 EDT 2003


----- Original Message -----
From: "Lowden, James K" <LowdenJK at bernstein.com>
To: "'Joel Apter'" <japter at ibxtech.com>; "'FreeTDS Development Group'"
<freetds at lists.ibiblio.org>
Sent: Thursday, June 12, 2003 2:36 PM
Subject: RE: [freetds] FreeTDS, unixODBC, and libodbc++


> > From: Joel Apter [mailto:japter at ibxtech.com]
> > Sent: June 12, 2003 12:42 PM
> >
> > Error setting pointer statement option:
> > [unixODBC][Driver Manager]Invalid attribute/option identifier
> ...
> > odbc:SQLColAttributes: fDescType is 4
> > odbc:SQLColAttributes: fDescType is 5
> > odbc:SQLColAttributes: fDescType 5 not catered for...
>                                      ^^^^^^^^^^^ clue
> > odbc:SQLColAttributes: fDescType is 3
> >
> > I'm not sure if this means anything.  What I am wondering is,
> > is this an issue with freetds, unixodbc, or libodbc++ (or all
> > of them, or none??)?  Has anyone actually written a c++
> > application usually a similar driver/driver manager setup?
>
> Hi Joel,
>
> We don't get a lot of libodbc++ questions, and I'm not sure anyone's
gotten
> it more than minimally working.  OTOH, Frediano keeps making our ODBC
driver
> better and better.  It tends to squawk when asked to do something it can't
> yet do.
>
> The "not catered" message comes from src/odbc/odbc.c::SQLColAttributes
> (superseded by SQLColAttribute in the ODBC docs, btw).  I think fDescType
5
> might be SQL_COLUMN_SCALE, which we don't support.  If that's the issue,
> something like this might help:
>
>         case SQL_COLUMN_SCALE:
>                 switch (colinfo->column_type) {
>                 case SYBNUMERIC:
>                 case SYBDECIMAL:
>                         *pfDesc = colinfo->column_scale;
>                         break;
>                 default:
>                         *pfDesc = 0;
>                         break;
>                 }
>                 break;
>
> Could you see if that at least doesn't make the log message go away?
>

I'm not quite sure how I would implement that code since the libodbc++
libraries handles those datatypes internally.

> Do the libodbc++ tests report anything interesting?  Perhaps they have
finer
> grained checking of the underlying library that would help us flush out
> what's missing.
This is what happens when I run the dbmetadata test program that comes with
libodbc++:

Connecting to dsn=db, uid=username, pwd=password... done.
Product name                    : SQL Server
Product version                 : unknown version
Driver name                     : libtdsodbc.so
Driver version                  : 0.61
Driver ODBC version             : 3.0
Supports transactions           : Yes

Transaction support
===================

Error fetching information: Option not supported

And here is the tail of my tdsdump file after running dbmetadata:

2003-06-12 14:49:17.024453 processing result tokens.  marker is
e3(ENVCHANGE)
2003-06-12 14:49:17.024503 inside tds_process_default_tokens() marker is
e3(ENVCHANGE)
2003-06-12 14:49:17.024561 processing result tokens.  marker is  ab(INFO)
2003-06-12 14:49:17.024610 inside tds_process_default_tokens() marker is
ab(INFO)
2003-06-12 14:49:17.024712 processing result tokens.  marker is  fd(DONE)
2003-06-12 14:49:17.024764 inside tds_process_end() more_results = 0,
was_cancelled = 0
2003-06-12 14:49:17.024823 inside tds_process_result_tokens() state is
COMPLETED
SQLGetFunctions: fFunction is 999
odbc: not implemented: SQLGetInfo: option/type 10000(SQL_XOPEN_CLI_YEAR)
[category Added for ODBC 3.x]
odbc: not implemented: SQLGetInfo: option/type 72(SQL_TXN_ISOLATION_OPTION)
[category Data Source Information]

To me, it appears as though there are several things that the libodbc++
libraries require that are yet to be implemented in freetds
(SQLColAttributes and SQLGetInfo, for example).  Please note, this is not
meant as a complaint at all (more of a wishlist :)).  I am quite impressed
with FreeTDS's functionality thus far.

>
> What does unixODBC say about their message?  Is there a way to get more
(ie,
> any) details?  As in, say, which identifier was invalid, and what its
value
> was?
>
Not totally sure what kind of debug/logging options unixODBC has to further
diagnose this issue from the driver manager's standpoint.  I'll look into
though, if I find anything I'll let you guys know.

Thank you for your time to respond, I appreciate your opinion on the
situation so far.  :)

I guess its back to the C functions for me.

BTW, does anyone happen to know of a lightweight C++ library that wraps some
of the basic C ODBC functions for you?

> --jkl
> -----------------------------------------
> The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.
>
>




More information about the FreeTDS mailing list