[freetds] Ongoing work for released version of FreeTDS version 0, 64, 0, 6182

ZIGLIO, Frediano, VF-IT Frediano.Ziglio at vodafone.com
Wed Jan 16 04:20:27 EST 2008


> 
> We are making corrections to FreeTDS driver version 64.
> 
>  
> 
> We have found some important bugs and fixed them.
> 
>  
> 
> Of course, we will contribute back the source so that anyone who wants
> to can back-patch the current development version.
> 
>  
> 
> It is also possible that some of our changes cannot be used by the
> standard version of FreeTDS, so any merge should be examined closely.
> 
>  
> 
> We are also implementing extensive testing over a large number of
> platforms (there will be hundreds of thousands of tests performed
> against the source).
> 
> 

Fine.
 
> 
> I guess what I am saying is that the FreeTDS group is 
> essentially going
> to get free commercial support in a sense (we already have 
> and are going
> to continue to expend resources to improve the driver).
> 
>  
> 
> Of course we expect also to benefit from continued growth of 
> the FreeTDS
> project.
> 

We are releasing version 0.82 and I noted that you are based on 0.64
without post patch. I think it would be better to update. I manage to
get a unified diff against 0.64. Included with notes

diff -ub ./convert_tds2sql.c new/convert_tds2sql.c
--- ./convert_tds2sql.c	2006-02-24 22:14:24.000000000 +0100
+++ new/convert_tds2sql.c	2008-01-16 09:40:37.938249787 +0100
@@ -54,6 +54,9 @@
 	DATE_STRUCT *dsp;
 	TIME_STRUCT *tsp;
 	TIMESTAMP_STRUCT *tssp;
+
+	TIMESTAMP_STRUCT ts;
+
 	SQL_NUMERIC_STRUCT *num;
 
 	int ret = TDS_FAIL;
@@ -140,11 +143,11 @@
 
 		tds_datecrack(SYBDATETIME, &(ores.dt), &dr);
 
-		dsp = (DATE_STRUCT *) dest;
+		ts.year = dr.year;
+		ts.month = dr.month + 1;
+		ts.day = dr.day;
 
-		dsp->year = dr.year;
-		dsp->month = dr.month + 1;
-		dsp->day = dr.day;
+		memcpy(dest, &ts, sizeof(DATE_STRUCT));
 
 		ret = sizeof(DATE_STRUCT);
 		break;
@@ -157,11 +160,11 @@
 
 		tds_datecrack(SYBDATETIME, &(ores.dt), &dr);
 
-		tsp = (TIME_STRUCT *) dest;
+		ts.hour = dr.hour;
+		ts.minute = dr.minute;
+		ts.second = dr.second;
 
-		tsp->hour = dr.hour;
-		tsp->minute = dr.minute;
-		tsp->second = dr.second;
+		memcpy(dest, &ts, sizeof(TIME_STRUCT));
 
 		ret = sizeof(TIME_STRUCT);
 		break;
@@ -174,15 +177,15 @@
 
 		tds_datecrack(SYBDATETIME, &(ores.dt), &dr);
 
-		tssp = (TIMESTAMP_STRUCT *) dest;
+		ts.year = dr.year;
+		ts.month = dr.month + 1;
+		ts.day = dr.day;
+		ts.hour = dr.hour;
+		ts.minute = dr.minute;
+		ts.second = dr.second;
+		ts.fraction = dr.millisecond * 1000000u;
 
-		tssp->year = dr.year;
-		tssp->month = dr.month + 1;
-		tssp->day = dr.day;
-		tssp->hour = dr.hour;
-		tssp->minute = dr.minute;
-		tssp->second = dr.second;
-		tssp->fraction = dr.millisecond * 1000000u;
+		memcpy(dest, &ts, sizeof(TIMESTAMP_STRUCT));
 
 		ret = sizeof(TIMESTAMP_STRUCT);
 		break;
@@ -190,7 +193,7 @@
 #ifdef SQL_C_SBIGINT
 	case SQL_C_SBIGINT:
 	case SQL_C_UBIGINT:
-		*((TDS_INT8 *) dest) = ores.bi;
+		memcpy(dest, &ores, sizeof(TDS_INT8));
 		ret = sizeof(TDS_INT8);
 		break;
 #endif
@@ -198,14 +201,14 @@
 	case SQL_C_LONG:
 	case SQL_C_SLONG:
 	case SQL_C_ULONG:
-		*((TDS_INT *) dest) = ores.i;
+		memcpy(dest, &ores, sizeof(TDS_INT));
 		ret = sizeof(TDS_INT);
 		break;
 
 	case SQL_C_SHORT:
 	case SQL_C_SSHORT:
 	case SQL_C_USHORT:
-		*((TDS_SMALLINT *) dest) = ores.si;
+		memcpy(dest, &ores, sizeof(TDS_SMALLINT));
 		ret = sizeof(TDS_SMALLINT);
 		break;
 
@@ -218,12 +221,12 @@
 		break;
 
 	case SQL_C_DOUBLE:
-		*((TDS_FLOAT *) dest) = ores.f;
+		memcpy(dest, &ores, sizeof(TDS_FLOAT));
 		ret = sizeof(TDS_FLOAT);
 		break;
 
 	case SQL_C_FLOAT:
-		*((TDS_REAL *) dest) = ores.r;
+		memcpy(dest, &ores, sizeof(TDS_REAL));
 		ret = sizeof(TDS_REAL);
 		break;
 


This code only fixes unaligned binded data. Binded data should be
aligned so I don't think should be merged. Also code for TIME_STRUCT
introduce a read of uninitialized data, I don't think is what you
wanted.



diff -ub ./odbc.c new/odbc.c
--- ./odbc.c	2006-06-29 23:38:13.000000000 +0200
+++ new/odbc.c	2008-01-16 09:40:47.924301437 +0100
@@ -448,7 +448,6 @@
 	tmp_size = stmt->ard->header.sql_desc_array_size;
 	stmt->ard->header.sql_desc_array_size = stmt->sql_rowset_size;
 	tmp_offset = stmt->ard->header.sql_desc_bind_offset_ptr;
-	stmt->ard->header.sql_desc_bind_offset_ptr = NULL;
 
 	/* TODO errors are sligthly different ... perhaps it's better to
leave DM do this job ?? */
 	ret = _SQLFetch(stmt);



>From odbc documentation of SQLExetendedFetch:

SQLExtendedFetch does not support binding offsets (the
SQL_ATTR_ROW_BIND_OFFSET_PTR statement attribute).

Did you have a test that state the opposite??


@@ -2356,7 +2355,8 @@
 			return SQL_ERROR;
 
 		/* TODO other types for date ?? SQL_TYPE_DATE,
SQL_TYPE_TIME */
-		if (drec->sql_desc_concise_type == SQL_TIMESTAMP)
+		if ((drec->sql_desc_concise_type == SQL_TIMESTAMP) ||
+		    (drec->sql_desc_concise_type == SQL_TYPE_TIMESTAMP)
)
 			drec->sql_desc_length = sizeof("2000-01-01
12:00:00.0000")-1;
 		else
 			drec->sql_desc_length = col->column_size;


Fine, I think I can commit this without problems.


@@ -3536,7 +3536,7 @@
 		}
 
 		tdsdump_log(TDS_DBG_INFO1, "Creating prepared
statement\n");
-		if (tds_submit_prepare(tds, stmt->prepared_query, NULL,
&stmt->dyn, params) == TDS_FAIL) {
+		if (tds_submit_prepare(tds, stmt->prepared_query, NULL,
&stmt->dyn, params) == TDS_FAIL && stmt->need_reprepare != 1) {
 			tds_free_param_results(params);
 			ODBC_RETURN(stmt, SQL_ERROR);
 		}

Mmm... this means deferring prepare on submit error... yes this can
help!
Do you have any test for this?


diff -ub ./odbc_util.c new/odbc_util.c
--- ./odbc_util.c	2006-02-24 22:14:25.000000000 +0100
+++ new/odbc_util.c	2008-01-16 09:39:26.306000956 +0100
@@ -505,10 +505,12 @@
 		size = column_prec + 2;
 		break;
 	case SQL_DATE:
+	case SQL_TYPE_DATE:
 		/* FIXME check always yyyy-mm-dd ?? */
 		size = 19;
 		break;
 	case SQL_TIME:
+	case SQL_TYPE_TIME:
 		/* FIXME check always hh:mm:ss[.fff] */
 		size = 19;
 		break;

Fine, I think I can commit this without problems.

>  
> 
> At any rate, attached is a current (development) zip of the 
> odbc source.
> I have not carefully examined if we made any changes to other
> sub-projects or even what has been changed in this zip, but you can
> easily determine it yourself by using diff.  We were not able 
> to use the
> code without these changes.
> 
>  
> 
> We are interested in the current work involving UNICODE.
> 
>  
> 
> Is it possible to get a summary about the current state of that work?
> 


Depending on what you means by Unicode reply can change from implemented
to unimplemented.

freddy77



More information about the FreeTDS mailing list