FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

> > > Bug 2:  I don't see what tds is doing for us.  Perhaps the 
> > > computer is curious?    
> > 
> > I assume you are referring to why the conversion stuff is in libtds? 
> 
> No, just to the local variable.  Bill says it's my fault. :)

Ah, my bad.

> > Basically we had no other place to put it since conversion is 
> > shared by all libraries.  I'm starting to consider that conversion, 
> > iconv, thread
> > safety, and some other miscellenia should be moved somewhere 
> > else like a
> > 'common' directory.  It's not protocol related but it is 
> > shared among the API's.
>
> Probably a good idea.  I don't think it's "wrong" to think of all the common
> stuff as "tds" related; after all, all these datatypes and conversions exist
> because they're defined by the TDS protocol, or at least by the folks who
> invented it.  It would be helpful, though, to split the wire-level stuff,
> which is particularly nasty and hard, from the "softer" utility functions
> that are neither TDS- nor API-specific.  I suppose it's inevitable for that
> area to grow, since tdslib is basically complete.  

the tds directory is getting a bit big for my taste...we'll probably have
to deal with it sooner or later.
 
> > > Bug 3:  Because tds_convert has no dbproc, it can't call 
> > > the proc's error handler.  
> 
> > You can call tds_client_msg().  The tds layer 
> > calls the API's
> > handler (which unlike the clients handlers are always installed), the
> > API's handler is then responsible for deciding which 
> > application handler
> > gets called, typically by casting the tds->parent back to a 
> > API specific
> > structure (ala DBPROCESS).
> > So no, TDS can not call a application handler but he can call the
> > installed API message handler which can.
> 
> I see.  I didn't know about tds_client_msg().  There are two fine points I
> want to raise.  I'm sure you've thought about them, but I don't know what
> you decided.  
> 
> 1.    The vendor implementations offer no default error handler.  No
> handler means no message.  I'm guessing you decided to install a default one
> to make errors more obvious.  And your "clientele" doesn't mind seeing stuff
> on stderr.  

That is up to the API message handler, so for instance dblib could spill
messages and ctlib could forward them to /dev/null.  But i think the
proper behaviour for all APIs should be to write them with tdsdump_log().
If logs are on they appear there if not, well you really should have set a
handler if you wanted them.

> 2.    Microsoft allows per-process handlers, with dbprocerrhandle and
> dbprocmsghandle.  That allows the application to write a non-reentrant
> handler, because they ensure that two threads on two procs will have their
> errors routed each through its own handler.  Otherwise, the dberrproc has to
> be able to ... well, you see what I mean.  I don't know how Sybase apps work
> in this regard, but as we add thread support we're bound to bump into it.

ctlib is even a bit more complicated as you can hook messages to either
the connection or the context. It's pretty simple just add a function
pointer to DBPROCESS and test it inside dblib_handle_info_message and
dblib_handle_error_message.  This is basically the only reason tds->parent
exists and it's held up well over the years, IMNSHO.

> Thanks for clearing that up.  
> 
> --jkl

Brian