FreeTDS Development Group

["Ian Harding" <ianh AT tpchd.org>]

Well, I looked in my server.log and guess what I see?  Tons of 

Notice: Ns_FreeTDS_Msg_Handler(envision): <error message> 

messages.  Doh!  I thought I looked there.  In fact I did, but I was looking 
for 'Error:'.

I did not wrap the ns_db call in a catch [] because I figured if there was an 
error I would just get an ugly 'Could not process this request due to an 
error at the server' message and I am just testing at this point.  These 
errors seem not to cause that to happen.

They are definitely not in my tdsdump logs.

I am my own worst enemy sometimes.  Oh well, at least I got you on the list!  
Thanks for your time!

Ian

Ian A. Harding
Programmer/Analyst II
Tacoma-Pierce County Health Department
(253) 798-3549
mailto: ianh AT tpchd.org

>>> dossy AT panoptic.com 07/26/01 10:45AM >>>
On 2001.07.26, Brian Bruns <camber AT ais.org> wrote:
> > 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).

Are they complete, though?

I would hate to build upon one of the CLIs just to find that while
the underlying TDS layer is complete and correct, the CLI implementation
is busted, which is why my nsfreetds is broken ...

Until FreeTDS becomes a lot more complete and stable (like, when
you folks feel comfortable releasing a 1.0 version, perhaps) then
I'll probably consider switching nsfreetds to use ctlib or dblib.

Or, I might just leave it using libtds, which I actually think is
easier to work with.  ;-)

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

I don't mind at all.  This is why when I release nsfreetds I
specify what version of FreeTDS the driver works with -- if you
go change FreeTDS, as long as you make old versions available for
download, people can still use nsfreetds.  Then, I can update
nsfreetds to work with the latest libtds and release it ...
it's quite sane.

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

Or, at least make it an option to always log errors regardless of
if there's a private error handler registered or not.  Although,
if people are using tdsdump to log errors, they probably want to
see everything, anyway... so you may not really need to make this
a seperately configurable option.  Cool.

-- Dossy

-- 
Dossy Shiobara                       mail: dossy AT panoptic.com 
Panoptic Computer Network             web: http://www.panoptic.com/ 

---
You are currently subscribed to freetds as: [ianh AT tpchd.org] 
To unsubscribe, forward this message to 
leave-freetds-132781U AT franklin.oit.unc.edu