FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: January 2, 2003 1:19 PM
> > 
> > In db-lib, the client provides a "message handler" callback 
> function that
> > the library invokes whenever a server message arrives.  I 
> don't know how
> > that's done in ODBC, or how well we support it.  
> 
> In ODBC this is done using error reporting procedures. Using new API
> (SQLGetDiag*) many warnings/errors can be returned. But this require
> full rewrite of error handling (error now is global while should be
> related to environment/connection/statement).

I don't see what has to be rewritten unless it's something in libodbc.  

libtds processes messages as they arrive from the server, and invokes
whatever handler is installed for that *connection*.  What's "global" about
that?  

The message arrives with some context information, but without any
"statement ID".  AFAIK, the message is always sent immediately after the
offending statement, so the application can usually infer where things went
wrong.  Errors stemming from stored procedures or triggers can be tricky to
pin down, though.  

It's up to libodbc to park the message where the application can read it
with SQLGetDiagRec().  That's pretty clearly what Microsoft does, from their
docs:

"The timing of calling SQLGetDiagRec is critical when output from PRINT or
RAISERROR statements is included in a result set. The call to SQLGetDiagRec
to retrieve the PRINT or RAISERROR output must be made immediately after the
statement that receives SQL_ERROR or SQL_SUCCESS_WITH_INFO."

The documentation goes on to say that the application must pay close
attention to the return codes of SQLExecute and SQLMoreResults, alternating
as need be between fetching data and fetching error information.  Nothing is
cached or stacked, apparently; messages and data arrive interleaved and must
be retrieved in the same order!  

That sounds dreadful to me for the application programmer; I'd much prefer
callbacks.  But it's pretty easy for the library programmer.  

--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.