Skip to Content.
Sympa Menu

freetds - Re: [freetds] 0.65 (or whatever) TODO

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] 0.65 (or whatever) TODO
  • Date: Mon, 16 Apr 2007 09:43:26 +0200

>
> ZIGLIO, Frediano, VF-IT wrote:
> > There was some bugs in bsqlodbc (committed), now I have (I
> compiled with
> > no dm)
>
> Thank you.
>
> > $ cat hg.sql | ./bsqlodbc -S xxx -U test -P test
> > "[FreeTDS][SQL Server]hello"
> > "[FreeTDS][SQL Server]goodbye"
> > $ cat hsg.sql | ./bsqlodbc -S xxx -U test -P test
> > "[FreeTDS][SQL Server]hello"
> > one
> > ----------
> > 1
> > "[FreeTDS][SQL Server]goodbye"
> > two
> > ----------
> > 2
> >
> > So... it seems fine. Personally I would use ODBC 3 in
> bsqlodbc with an
> > option for ODBC 2.
>
> I'm happy to use ODBC 3; I'm not sure how. ISTR I linked bsqlodbc to
> Sybase's libraries at one time (disk since crashed). I'm not sure I
> committed the changes I made to make that work. I remember there was a
> function call to set the version. Is that what you mean?
>
> I'll redo my Sybase test and let you know.
>

from src/odbc/unitetests/common.c

if (use_odbc_version3)
SQLSetEnvAttr(Environment, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)
(SQL_OV_ODBC3), SQL_IS_UINTEGER);

> > There are some problems:
> > - SQLFetch/SQLMoreResults return errors even on
> SQL_NO_DATA. You have to
> > read them (fixed in bsqlodbc)
> > - unixODBC till 2.2.11 (I don't know 2.2.12) DO NOT read errors on
> > SQL_NO_DATA
> > - ODBC 2 collapse recordset and errors
>
> Noted! I have unixODBC-2.2.12. Do you mean it's a DM problem, or an
> isql problem (not reading errors on SQL_NO_DATA)?
>

DM (so isql is affected too).

> > > Example 1: losing messages
> > > --------------------------
> > >
> > > $ cat hsg.sql
> > > print 'hello' select 1 as one print 'goodbye'
> > > select 2 as two
> > >
> > > $ cat hsg.sql | isql -vb $S $U $P # loses 'goodbye' message
> > > ...
> > > SQL> [01000][unixODBC][FreeTDS][SQL Server]hello
> > > [ISQL]INFO: SQLExecute returned SQL_SUCCESS_WITH_INFO
> > > +------------+
> > > | one |
> > > +------------+
> > > | 1 |
> > > +------------+
> > > SQLRowCount returns 1
> > > 1 rows fetched
> > > SQL> +------------+
> > > | two |
> > > +------------+
> > > | 2 |
> > > +------------+
> > > SQLRowCount returns 1
> > > 1 rows fetched
>
> The 'goodbye' message was lost. Is this an isql problem, too?
>
> Thanks for fixing bsqlodbc and for explaining the reversed messages in
> unixODBC's isql. If the lost messages are an isql bug, too, and if
> bsqlodbc behaves well with Sybase's driver, then I'm happy to
> prepare to
> release 0.65.
>

Watchnig again log I realize that the problem seems in DM too... from
log:

[ODBC][32028][SQLExecute.c][344]
Exit:[SQL_SUCCESS_WITH_INFO]
DIAG [01000] [FreeTDS][SQL Server]hello
DIAG [01000] [FreeTDS][SQL Server]goodbye

so DM read errors in the correct order however

[ODBC][32028][SQLError.c][342]
Entry:
Statement = 0x8a8b978
SQLState = 0xbf8c08fe
Native = 0xbf8c0700
Message Text = 0xbf8c0709
Buffer Length = 500
Text Len Ptr = 0xbf8c0706
[ODBC][32028][SQLError.c][379]
Exit:[SQL_SUCCESS]
SQLState = 01000
Native = 0xbf8c0700 -> 0
Message Text = [[unixODBC][FreeTDS][SQL
Server]goodbye]
[ODBC][32028][SQLError.c][342]
Entry:
Statement = 0x8a8b978
SQLState = 0xbf8c08fe
Native = 0xbf8c0700
Message Text = 0xbf8c0709
Buffer Length = 500
Text Len Ptr = 0xbf8c0706
[ODBC][32028][SQLError.c][379]
Exit:[SQL_SUCCESS]
SQLState = 01000
Native = 0xbf8c0700 -> 0
Message Text = [[unixODBC][FreeTDS][SQL
Server]hello]
[ODBC][32028][SQLError.c][342]
Entry:
Statement = 0x8a8b978
SQLState = 0xbf8c08fe
Native = 0xbf8c0700
Message Text = 0xbf8c0709
Buffer Length = 500
Text Len Ptr = 0xbf8c0706
[ODBC][32028][SQLError.c][379]
Exit:[SQL_NO_DATA]
[ODBC][32028][SQLError.c][424]
Entry:
Connection = 0x8a30130
SQLState = 0xbf8c08fe
Native = 0xbf8c0700
Message Text = 0xbf8c0709
Buffer Length = 500
Text Len Ptr = 0xbf8c0706
[ODBC][32028][SQLError.c][461]
Exit:[SQL_NO_DATA]

so SQLError return errors in the wrong order :(. I'll look at unixODBC
source.
A bit earlier.. unixODBC read all errors from driver cache them and
return to application. This cause some driver implement SQLError in
different ways. Some drivers remove error from list some other not... so
to be coherent unixODBC implement SQLError! Also it didn't try to get
errors from driver if SQL_NO_DATA to avoid a driver call. However they
didn't take in account that SQL_NO_DATA does not mean no diagnostic is
returned...

I don't understand... why bsqlodbc have to behave well with Sybase's
driver??

> I just want to be able to tell people which unixODBC and
> DBD::ODBC module
> to use to get reliable message delivery.
>

Take into account that DBD::ODBC use ODBC 3 by default.

freddy77





Archive powered by MHonArc 2.6.24.

Top of Page