freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
- To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
- Subject: [freetds] devel: row changes
- Date: Tue, 1 Feb 2005 14:22:49 +0100
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] devel: row changes,
ZIGLIO, Frediano, VF-IT, 02/01/2005
- <Possible follow-up(s)>
- RE: [freetds] devel: row changes, Thompson, Bill D (London), 02/01/2005
- RE: [freetds] devel: row changes, ZIGLIO, Frediano, VF-IT, 02/01/2005
- RE: [freetds] devel: row changes, Thompson, Bill D (London), 02/01/2005
Archive powered by MHonArc 2.6.24.