Skip to Content.
Sympa Menu

freetds - RE: [freetds] First select fails on newly created/populated table fails

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] First select fails on newly created/populated table fails
  • Date: Thu, 10 Apr 2003 19:11:03 -0400 (EDT)


On Thu, 10 Apr 2003, Lowden, James K wrote:

> Several of us have noted that the ct-lib API closely mimics the TDS
> protocol. It was Sybase's second try, and it shows. (It also suffers IMHO
> somewhat from Fred Brooks's "second system syndrome"). One radical
> hypothesis: ct-lib should be libtds. IOW, db-lib and ODBC could be
> implemented in terms of ct-lib. After all, what can they do that ct-lib
> can't, if ct-lib can do whatever TDS does?

Ack! Some things to think about: MS TDS will diverge more and more with
time, so the ctlib is tds argument may not be true inperpetuity. Also
this does nothing to solve the libtds does too much argument, qute the
opposite. It also suffers from the ODBC-as-second class citizen problem.

Second argument against, Sybase does not do that either. Although libs
below libct (libcomn libintl etc...) are shared.

> Another way to look at it is that libtds encompasses more than it needs to.
> I think it's important that wire-level differences in the TDS flavors be
> isolated from the client libraries. There shouldn't be any tests for TDS
> version or endianism outside libtds. There are some utility functions, like
> conversions, that it can do. But it's not terribly clear to me that we want
> three client libraries all interpreting tokens coming off the wire. It
> seems to me that one could do that job better.

non-tds common stuff should be split off, definately. libtdscomn? One of
those never gotten to projects, since once upon a time that was
only conversion stuff. Now it's convert, iconv, numerics, portable string
functions, threadsafety, et al.

> Does any of this make sense to you? Is it tempting, or tempting fate?
>
> If you like the idea, we could talk about how to create a merged ct-tds-lib.
> For the time being, db-lib and ODBC would continue to use libtds as it is.
> In the future, they'd attach themselves to the new ct-lib, and the old
> libtds would be retired.
>
> If you don't like the idea, perhaps you could describe the changes needed in
> the result processing functions, we can better understand the implications
> of the choices?

my vote (for what it is currently worth) is to change libtds as needed,
radically if necessary.

Brian




Archive powered by MHonArc 2.6.24.

Top of Page