FreeTDS Development Group

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

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

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

in bocca al lupo!!

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 13:23
To: FreeTDS Development Group
Subject: [freetds] devel: row changes


Well.. starting from this comment

        /* FIXME this is data related, not column */
        /** size written in variable (ie: char, text, binary). -1 if
NULL. */
        TDS_INT column_cur_size;

i tried to join null flag (inside row) + column_cur_size into row
(current_row buffer in TDSRESULINFO). The results was terrible... very
high changes and code was not so readable (with all bad
conseguences...). So I stopped fixing problem raised and after some time
I realize that I was fixing just row buffering in dblib... which didn't
work since 0.53... so all that complicate code just for nothing (as you
know there are many reason to remove this row from libTDS).
I discard all code and instead of putting null flag + column_cur_size
into row I collapsed it in column_cur_size. Result it's very fine.
Removed tds_clr_null/tds_set_null/tds_get_null, null_info_size (and
related ugly code). Just: if column_cur_size is -1 column it's NULL if
>=0 data are present (a column can't be NULL having a size and
viceversa). 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. Perhaps bcp_column_data
should->datalen be column_cur_size too?? Would be fine to have a
TDSSOCKET->column_data field (that point do data) instead of a
column_offset and a flag to indicate if data it's allocate or points
just to somewhere else (like a row handled by upper layer libraries??).

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