[freetds] First select fails on newly created/populated table fails
Thompson, Bill D (London)
ThompBil at exchange.uk.ml.com
Fri Apr 11 04:48:53 EDT 2003
Brian, James - thanks for the input. I'll mull it over some more.
A few (failry random) points...
Whatever's done, I'm keen to minimise disruption to the dblibrary
Could we code a new version of the tds results/row processing that could
live alongside the existing functions temporarily ?
I disagree with Brian's point on MS TDS - I think that they'll leave TDS
alone pretty much.
I base this view on what's happened with server side cursors: Whereas Sybase
added significantly on to the TDS protocol to support this functionality,
coding a whole new raft of messages, MS preferred to use the existing
protocol to execute "pseudo system stored procedures" - sp_cursor and
friends. I think they would go with this approach for any further additions.
Could Freddy give us a view on the odbc API in this area ? is it well
serviced by the existing TDS functions ? are there any problem areas or code
that you regard as "fudged" due to inadequacies in the TDS layer ?
> -----Original Message-----
> From: Brian Bruns [SMTP:camber at ais.org]
> Sent: 11 April 2003 00:11
> To: FreeTDS Development Group
> Subject: RE: [freetds] First select fails on newly created/populated
> table fails
> 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
> > 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
> > 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
> > version or endianism outside libtds. There are some utility functions,
> > conversions, that it can do. But it's not terribly clear to me that we
> > 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
> > For the time being, db-lib and ODBC would continue to use libtds as it
> > 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
> > of the choices?
> my vote (for what it is currently worth) is to change libtds as needed,
> radically if necessary.
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
More information about the FreeTDS