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: Wed, 21 Jan 2004 10:35:23 +0000

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?

Cheers

Jim

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