FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Thu, 26 Jul 2001, Dossy wrote:

> Hi,
> 
> I'm the one responsible for the nsfreetds driver, so I figured
> I should at least pop in on the mailing list and pick up this
> thread.  Can't just leave poor Ian out there to dry all by
> himself.  :-)

Hello, I thought I was pretty aware of all things freetds, but this
was a pleasant surprise.
 
> > Date: Wed, 25 Jul 2001 20:35:21 -0400 (EDT)
> > From: Brian Bruns <camber AT ais.org>
> > 
> [...]
> > ohmagosh, it uses the tds layer directly...neat.
> 
> I supposed I'm supposed to try and make ctlib or dblib work,
> instead ... but given the still-in-development nature of
> FreeTDS, I felt safer using the TDS layer directly.

That is fine.  The reason I recommend one of the CLIs is that they are
defined externally as to their function and the API will never change (it
may be added to, but not incompatibly).  libtds is our own creation and
isn't guaranteed to remain consistant (although I don't haul off and
change it for no reason).  If you don't mind this fact, then I certainly
don't, the recommendation is just so people don't mistake the
nature of libtds.  libtds will give you slightly better performance
however, but it is probably negligible.
 
> > Either one of two things is happening.  The message is getting delivered
> > to nsfreetds and is being ignored (which I can't see how) or msg_number is
> > 0 (otherwise the error would show up in the tds log).
> 
> Or, the error IS being logged into the AOLserver log/server.log, and
> Ian isn't looking there.

Now there is a possibility that makes sense. I should probably log errors
to the tds dump file regardless of whether they're being caught or not...
 
> Also, any ns_db call that fails should throw an exception that
> will throw an error into log/server.log _or_ can be caught by
> the application by wrapping the ns_db with a
> 
>   if [catch {ns_db ...} msg] { ... }
> 
> block.
> 
> -- Dossy

Thanks for the info,

Brian