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: Mon, 26 Jun 2006 11:24:54 +0200

...
> >>
> >>ODBC Message: SQLState 01000 ErrorMessage [unixODBC][FreeTDS][SQL
> >>Server]d NativeServerError 0
> >>ODBC Message: SQLState 01000 ErrorMessage [unixODBC][FreeTDS][SQL
> >>Server]c NativeServerError 0
> >>ODBC Message: SQLState 01000 ErrorMessage [unixODBC][FreeTDS][SQL
> >>Server]b NativeServerError 0
> >>ODBC Message: SQLState 01000 ErrorMessage [unixODBC][FreeTDS][SQL
> >>Server]a NativeServerError 0
> >>
> >
> >
> > :(
> > I don't understand the reason why they came in reverse
> order... is DM or
> > a rank_errors problem? Could you post a short test?
>
> I don't understand why either. I did hack on it a bit but
> haven't yet
> found the source of the problem. I don't think rank_errors
> is at fault,
> because I dummied out rank_errors with an immediate return and it had
> the same behavior.
>
> > Did you use SQLError or SQLGetDiag*?
>
> I'm not calling either one directly. It's a DBI program, using
> DBD::ODBC with an odbc_err_handler callback. With so many layers of
> indirection involved, I couldn't figure out which component
> was at fault.
>

The better way is to enable loggings at different level. Use ODBC trace
to log ad unixODBC level and TDSDUMP to log at FreeTDS level. You can
also use dbi trace (I don't remember how) to log at dbi level. unixODBC
and FreeTDS should suffice.

freddy77





Archive powered by MHonArc 2.6.24.

Top of Page