Skip to Content.
Sympa Menu

freetds - RE: [freetds] bcp broken on TDS 5.0

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] bcp broken on TDS 5.0
  • Date: Mon, 26 Apr 2004 12:44:44 -0400

> From: Thompson, Bill D (London) [mailto:bill_d_thompson AT ml.com]
> Sent: April 26, 2004 11:46 AM
>
> 95% there...now of course I've gotten the benfit of
> hindsight, my new code
> is so much cleaner than the dblib version.

Ah, good. So only another 95% to go, eh?

> I guess I *should* try and backport said improvements into
> dblibrary, but I am short of time...

When you've got a working ct-blk, let's put it in as is. Refactoring
functionality into libtds makes more sense (to me, anyway, from here) than
backporting anything to db-lib. The Microsoft ODBC driver supports bcp as an
extension, too, you'll recall.

I'm not second guessing you regarding the degree of functional overlap
between the libraries or the less-than-meets-the-eye value of moving some of
it to libtds. It's just that when I hear "backport", it suggests shared
functionality. Besides, there are ways that db-lib's bcp would need to be
reorganized if I were to pursue my any-to-any idea, whereby the bcp
source/target combination could be two files or two servers.

--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.
If you, as the intended recipient of this message, the purpose of which is to
inform and update our clients, prospects and consultants of developments
relating to our services and products, would not like to receive further
e-mail correspondence from the sender, please "reply" to the sender
indicating your wishes. In the U.S.: 1345 Avenue of the Americas, New York,
NY 10105.






Archive powered by MHonArc 2.6.24.

Top of Page