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: "Lowden, James K" <LowdenJK AT bernstein.com>
  • 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 11:45:43 -0400

> From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> Sent: April 10, 2003 11:12 AM
>
> I could :
>
> Alter the behaviour of the generic functions so that
> ct-library can capture
> the level of knowledge it requires about the TDS stream.
> Unfortunately this would also mean changing the other API's ,
> which AFAIK
> don't currently have any problems in this area and are very stable.
>
> Or I could :
>
> Write some different results/row processing specially for
> ct-library either
> as new functions within the tds library or in ct-library itself.
> This has the obvious drawback of duplicate code, but safeguards the
> db-library and odbc code from possible problems.

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?

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.

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?

Regards,

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above. If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.





Archive powered by MHonArc 2.6.24.

Top of Page