FreeTDS Development Group

[James Vanns <jimv AT canterbury.ac.uk>]

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