freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Dossy <dossy AT panoptic.com>
- To: TDS Development Group <freetds AT franklin.oit.unc.edu>
- Subject: Re: Sybase SQL Anywhere
- Date: Thu, 26 Jul 2001 13:45:29 -0400
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/
-
Sybase SQL Anywhere,
Ian Harding, 07/05/2001
- <Possible follow-up(s)>
- Re: Sybase SQL Anywhere, Brian Bruns, 07/05/2001
- Re: Sybase SQL Anywhere, Ian Harding, 07/05/2001
- Re: Sybase SQL Anywhere, Ian Harding, 07/25/2001
- Re: Sybase SQL Anywhere, Brian Bruns, 07/25/2001
- Re: Sybase SQL Anywhere, Ian Harding, 07/25/2001
- Re: Sybase SQL Anywhere, Brian Bruns, 07/25/2001
- Re: Sybase SQL Anywhere, Ian Harding, 07/26/2001
- Re: Sybase SQL Anywhere, Dossy, 07/26/2001
- Re: Sybase SQL Anywhere, Brian Bruns, 07/26/2001
- Re: Sybase SQL Anywhere, Dossy, 07/26/2001
- Re: Sybase SQL Anywhere, Ian Harding, 07/26/2001
- Re: Sybase SQL Anywhere, Dossy, 07/26/2001
Archive powered by MHonArc 2.6.24.