[freetds] Bulkcopy in ct-lib
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Wed Feb 4 11:42:48 EST 2004
> 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.
I don't understand the reason of BCP_COLINFO. I think it's best to reuse
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...
More information about the FreeTDS