Skip to Content.
Sympa Menu

freetds - Re: dbconvert bugs

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Brian Bruns" <camber AT ais.org>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: dbconvert bugs
  • Date: Tue, 9 Jul 2002 13:35:38 -0400


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




Archive powered by MHonArc 2.6.24.

Top of Page