FreeTDS Development Group

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

Thanks James,

> As a design objective, IMO all wire services handled in libtds.  
> I hope the rewrite will push those kinds of low-level decisions down from
db-lib to libtds, and that we won't introduce more wire handling in ct-lib.

> Does that seem like a feasible, useful guideline to you?  

I'm happy with that. 

> Do you still want me to add src/tds/bcp.c?  

yes - at the least it could hold the wire handling code that currently is in
dblib/bcp.c - I'd prefer to call it src/tds/bulk.c though...
The wire handling code is restricted to the functions which bcp data INTO
the server ( _bcp_exec_in() and bcp_sendrow() )
The bcp out functionality ( _bcp_exec_out() ) uses
tds_process_result/row_tokens .
We already know that we may have problems with partial packets being
submitted to the wire, because we may find an error as we process each
column.
So, it would make sense for us to construct the "row" buffer beforehand (as
we do with TDS 5.0).
The code for assembling this may be different for ctlib and dblib ( the
binding being so different ), but it could store it in a common location.
I'm looking to see if we could use the "current_row" buffer that exists in
the TDSRESULTINFO structure. Its exactly the right length for TDS 7/8 (the
bcp row data being the same as normal row data). I'm pretty sure it'd hold
the TDS 5 packet as well.

Bill


> -----Original Message-----
> From: Lowden, James K [SMTP:LowdenJK AT bernstein.com]
> Sent: 04 February 2004 15:51
> To:   FreeTDS Development Group
> Subject:      RE: [freetds] Bulkcopy in ct-lib
> 
> > From: Thompson, Bill D (London) [mailto:bill_d_thompson AT ml.com]
> > Sent: February 4, 2004 7:21 AM
> > 
> > I'm working on and off - mostly off at the moment :-(  on the 
> > bulk library
> > parts of ct-lib
> > 
> > I'd been working on the premise, as agreed, that we would move common
> > functionality into libtds, and have the ct-library and 
> > dblibrary functions
> > call the common functions.
> > 
> > having started to cut the code, I'm beginning to doubt the 
> > wisdom of this,
> 
> Bill, you've looked at it and arrived at a conclusion.  I trust your
> judgement.  I'm sure you won't duplicate code; where you find commonality,
> you'll use it.  
> 
> It does sound to me like db-lib is a subset of ct-lib (once again).  If
> libtds had a tds_blk_bind() that supported ct-lib's bidirectionality,
> db-lib could call it, but only one way.  
> 
> As a design objective, IMO all wire services handled in libtds.  By that,
> I mean most of the functions in read.c and write.c should be used only by
> libtds; the client libraries should use higher level abstractions, things
> that insulate them from endianism and protocol flavors.  I hope the
> rewrite will push those kinds of low-level decisions down from db-lib to
> libtds, and that we won't introduce more wire handling in ct-lib.  
> 
> Does that seem like a feasible, useful guideline to you?  
> 
> Do you still want me to add src/tds/bcp.c?  
> 
> --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 an intended recipient of this commercial e-mail or
> advertisement, 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
> 
> 
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds