Skip to Content.
Sympa Menu

freetds - Re: [freetds] FreeTDS 0.64RC2 src/odbc/unittests/raiserror failure with unixODBC 2.2.11

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] FreeTDS 0.64RC2 src/odbc/unittests/raiserror failure with unixODBC 2.2.11
  • Date: Thu, 22 Jun 2006 09:33:59 +0200

>
> Frediano Ziglio wrote:
> > Il giorno mar, 20/06/2006 alle 13.54 -0400, entropy AT freetds.org ha
> > scritto:
> > > $ ./raiserror
> > > odbctest
> > > --------
> > >
> > > connection parameters:
> > > server: 'mdreports'
> > > user: 'reportdbo'
> > > password: '????'
> > > database: 'reportdb'
> > > use reportdb
> > > CREATE PROCEDURE #tmp1
> > > @InParam int,
> > > @OutParam int OUTPUT,
> > > @OutString varchar(20) OUTPUT
> > > AS
> > > SET @OutParam = @InParam
> > > SET @OutString = 'This is bogus!'
> > > SELECT 'Here is the first row' AS FirstResult
> > > RAISERROR('An error occurred.', @InParam, 1)
> > > SELECT 'Here is the last row' AS LastResult
> > > RETURN (0)
> > > RAISERROR('An error occurred.', 5, 1)
> > > Result=0 DIAG REC 1: State=01000 Error=50000:
> [FreeTDS][SQL Server]An
> > > error occurred.
> > > Result=100 DIAG REC 1: State=00000 Error=0:
> > > SQLGetDiagRec error!
> >
> > I have to say that is a nightmare to make
> > all DMs happy so many time ago I decided to get rid of all these
> > problems and do not use for tests...
>
> Oh dear. I thought this was fixed, once and for all.
>
> DBD::ODBC is IMO one of the most important uses of the FreeTDS ODBC
> driver. We can't tell people in the UG they can use it, and then say,
> "Oh, by the way, error message handling works only without a
> DM, and we
> don't know how to configure DBD::ODBC that way." Well, we
> *can*, but I
> don't think we should.
>

It works correctly with DBD::ODBC even if raiserror fails. The "problem"
is that some tests are very strict. Let me revise the story of raiserror
test (I don't remember it 100% correctly but I have to say that this
test was changed many times...)
- Tom Rogers report a problems, raiserror seems to not get catched by
our ODBC driver
- we found that some raiserror are threated differently based on
level... someone return SQL_ERROR some others SQL_SUCCESS_WITH_INFO
- knowing that NOCOUNT change things quite a lot I added test for
NOCOUNT and similarly I added a second select
- after some years someone reported that DBD::ODBC didn't work correctly
with raiserror... I analyzed that ODBC trace and reproduce the trace
with raiserror (perhaps I added here the second select...). msodbc
driver (DBD::ODBC works perfectly under Windows) behave the same...
problem closed?
- some months later someone reported the same problem... but test works
and trace seems correct... after a bit I realized that I was using ODBC
2 while DBD::ODBC use ODBC 3... it was a really nightmare... ODBC 2 do
not support recordset without rows while ODBC 3 support them. This means
that a raiserror followed by a select procude a single recordset with a
row error under ODBC 2 and two recordset under ODBC 3.
- I added a test to catch some return from procedure. This is useful to
accurate emulating msodbc done processing (and is not fully
implemented...)

> Two choices on this front:
>
> 1. Document how to use DBD::ODBC without a DM.
> 2. Make src/odbc/unittests/raiserror work with a DM (any one!).
>

2. well... I think that the better way is: no DM? full test, DM present
? relax test...
The problem with unixODBC (which I mainly use) is that under ODBC 2 do
not read errors if SQLMoreResults return SQL_NO_DATA so it filter the
raiserror notification...

> I can understand the frustration of trying to support many driver
> managers, particularly because there are so many versions out
> there. I
> don't think we're obliged to support every DM flavor, though.
> One would
> suffice.
>

We support iODBC and unixODBC... nobody claim that is using another DM
so I don't like the idea of removing one...

> I think it's enough to say "FreeTDS version 0.64 was tested
> with unixODBC
> 2.2.11" or whatever. That gives the user a starting point.
> We did just
> that in our last release.
>
> I also wonder whether the problem is in the DM or in our
> conformance to
> the ODBC spec. Sybase makes an ODBC driver, and I'd be
> surprised if no DM
> handled their messages correctly.
>

One day or the other I would like to test Sybase driver with our
tests...

> (I also know of course the 0.64 release has been long in
> gestation, to say
> the least. I'm planning to finish it very soon, now that I have some
> time. First I have to deal with sourceforge's CVS changes,
> then decide
> what to do with the changes to 0.64 since rc2.)
>

Mainly changes contains very serious fixes like not supported dates.

> Freddy, what do you think? How can we go about fixing this?
>

As suggested I would relax test if DM is used and suggest unixODBC.

bye
Frediano





  • Re: [freetds] FreeTDS 0.64RC2 src/odbc/unittests/raiserror failure with unixODBC 2.2.11, ZIGLIO, Frediano, VF-IT, 06/22/2006

Archive powered by MHonArc 2.6.24.

Top of Page