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: "Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>
  • To: "'FreeTDS Development Group'" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] First select fails on newly created/populated table fails
  • Date: Fri, 11 Apr 2003 09:48:53 +0100

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

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 ?

Bill


> -----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
> 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
>
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page