Skip to Content.
Sympa Menu

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

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: James Vanns <jimv AT canterbury.ac.uk>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Error handling...
  • Date: Thu, 22 Jan 2004 09:40:59 +0000

OK, cheers all!

Jim

On Wed, 2004-01-21 at 15:57, Lowden, James K wrote:
> > 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.
>
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
--
James Vanns BSc (Hons) MCP
Linux Systems Administrator
Senior Software Engineer (Linux / C & C++)
Canterbury Christ Church University College
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x24045370





Archive powered by MHonArc 2.6.24.

Top of Page