FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.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. 
> 

I fully agree. This means all tds_get/tds_write and bcp code.

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

I don't understand the reason of BCP_COLINFO. I think it's best to reuse
TDSCOLUMN instead.
I agree to build row buffer cause we similar implementation for others
stuff (reading rows, computed rows, parameters. It's not very good for
writing however it's better designed. I'd prefer in a future to
implement direct client writing and reading but this can wait...

Freddy77