Skip to Content.
Sympa Menu

freetds - RE: [freetds] Error handling...

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Lowden, James K" <LowdenJK AT bernstein.com>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Error handling...
  • Date: Wed, 21 Jan 2004 10:57:05 -0500

> From: James Vanns [mailto:jimv AT canterbury.ac.uk]
> Sent: January 21, 2004 5:35 AM
>
> OK, thanks for that. Yeah should have realised I could use
> err_handler.
> Could I use the same message handler for both 'messages' and 'errors'
> and to a test on some part of TDSMSGINFO such as msg_state or
> msg_level
> and execute different code depending on whether it's an error or not?

Jim,

I think when you look into it further, you'll find they have different
signatures, so you have to provide two distinct callbacks. Whether they in
turn use a common function is of course up to you.

Messages conveyed from the server arrive intact; you can rely on their
documented state/level information. Errors -- messages emitted by the
library -- are a bit ramshackle: those from libtds mostly conform to
Sybase's db-lib spec, but sometimes DTRT for ct-lib. (The 0.62 ODBC driver
is pretty good about emitting reasonable ODBC-standard errors, but you're
using libtds directly.)

There is a strong possibility that this area will see heavy revision by
yours truly in 0.63. libtds should emit ct-lib style errors, which can be
bitwise parsed by the other client libraries and mapped onto their schemes.
I'm sure you've seen comments in the code pointing in that direction.

All to say, I wouldn't lean too heavily on the error numbers coming out of
libtds.

--jkl

> On Tue, 2004-01-20 at 17:42, Lowden, James K wrote:
> > > From: James Vanns [mailto:jimv AT canterbury.ac.uk]
> > > Sent: January 19, 2004 1:34 PM
> > >
> > > OK, so shoot me but I'm confused by the TDS error
> handling/catching.
> >
> > It's only software, James. In the history of man, no one's
> been shot over
> > software. ;-)
> >
> > > For example, if I send a query to the server with
> tds_query_submit and
> > > that query fails (incorrect table name say) what would
> the return code
> > > be?
> >
> > The return code would indicate success, unless the query
> were not accepted
> > by the server. How things turned out for the query would
> be the subject of
> > the server's response. An incorrect table name would
> engender a message
> > packet from the server, which would be routed to
> tds_process_msg().
> >
> > > if the SQL command succeeds but returns no rows what then?
> >
> > Well, the query "create table #t (t int)" is not expected
> to return rows,
> > and doesn't, and is not an error. The response packet from
> the server can
> > indicate whether rows will be forthcoming, but in any case the
> > absence/presence of a resultset packet settles the matter.
> >
> > > I
> > > realise that the err_handler of the TDSCONTEXT structure can
> > > print error
> > > messages but what if I actually want to handle the error
> by using some
> > > code?
> >
> > I'm not sure I understand what you mean. Your handler is
> "some code", and
> > it can do anything it wants, be it print messages or whatever, eh?
> >
> > I think you're asking: I send a query, the query has a
> problem, the problem
> > is identified not to my mainline code but to my message
> handler; how does my
> > message handler communicate that error back to the mainline
> code in good
> > time?
> >
> > The answer is, basically, set a flag that your mainline
> code will inspect.
> > There's no race condition: the server will send its error
> packets ahead of
> > any data, so your row-processing logic won't be invoked
> before your message
> > handler.
> >
> > --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.






Archive powered by MHonArc 2.6.24.

Top of Page