[freetds] devel: row changes
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Tue Feb 1 11:33:43 EST 2005
> > 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
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!!
More information about the FreeTDS