FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

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