FreeTDS Development Group

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

Freddy,

It's been a while now, but I really worked at doing exactly as you
described with BCP. When I first looked at it, it seemed the obvious
thing to do.

I can't remember all the details, but it turned out that the ctlib 
bcp functions had far more in common with other ct-library functions 
than they had with the db-library bcp functions. I ended up creating 
shared code between ct-library and blk-library, rather than between 
db-library bcp and blk-library. 

I remember thinking that if I tried to  create common bcp code in 
the tds-library, that code would be far more complicated and difficult
to maintain than if we kept the two bcp implementations separate.
I wrote some mail at the time...

I would focus your efforts elsewhere If I were you...

Bill

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of ZIGLIO,
Frediano, VF-IT
Sent: 01 February 2005 16:34
To: FreeTDS Development Group
Subject: RE: [freetds] devel: row changes


> 
> Freddy,
> 
> > I realize that I was fixing just row buffering in dblib... 
> > which didn't work since 0.53... 
> 
> I didn't know that it didn't work. Perhaps we should get it
> working afterwards...
> 

Well... there are two reason why row buffering don't work in dblib:
1- column_cur_size information it's not stored in row, so you loose this
information
2- text are not handled correctly (causing leaks)

I think it's better to change row handling before fixing row
buffering... noone complained about row buffering and we are more free
to change code.

> > Now I'm looking at BCP code... similar issue relate to
> > BCPCOLDATA. Why datalen and null_column ?? 
> > Perhaps it would be better to remove null_column and 
> > use only datalen.
> 
> To some extent, it's a matter of style. I tend to prefer using
> extra flags and indicators rather than overload existing ones.
> Sometimes it makes code easier to understand, and I regard that
> as more important than saving a few bytes storage here and there.
> In this case though, I wouldn't argue if you changed it...
> 
> In terms of storing the row data. Are you saying we should store 
> returned data inside the column structures rather than in 
> current_row ? I've long thought it would be better that way if you
> want to give it a go.As a by-product I hope you can do away with 
> storing RPC/Dynamic parameters in current_row type format.
> 

If we don't need to store row cause we want to use (I still don't know
how) direct binding it's normal that row buffering should be removed.
Could you describe me briefly the main differences between dblib BCP and
ctlib BCP. From what I see dblib it's bound to file while ctlib it's
bound to client variables... I think to port ctlib way to libTDS and use
libTDS to code dblib BCP. Do you think this it's the better way?? Do you
have any pending patch for BCP? You are the BCP man :)...

> in bocca al lupo!!
> 

Crepi :)

> Bill
> 

bye
  freddy77
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds 
--------------------------------------------------------
 
If you are not an intended recipient of this e-mail, please notify the 
sender, delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Click here for important additional terms relating to this 
e-mail.     http://www.ml.com/email_terms/ 
--------------------------------------------------------