FreeTDS Development Group

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

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

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

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

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.  

> Frediano's patch merely deals with the fact that having 
> global API handler
> function pointers means that we can not have dblib and ctlib 
> linked to the
> same binary and expect messages to work, or worse we'll cast 
> CS_CONNECTION to a DBPROC and segfault the whole thing.

Ah, but if it was C++, we could use virtual functions.... ;)

Thanks for clearing that up.  

--jkl