freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
[freetds] [ freetds-Patches-1583025 ] SQL Native Client compatibility updates
- From: "SourceForge.net" <noreply AT sourceforge.net>
- To: noreply AT sourceforge.net
- Subject: [freetds] [ freetds-Patches-1583025 ] SQL Native Client compatibility updates
- Date: Fri, 06 Apr 2007 02:10:54 -0700
Patches item #1583025, was opened at 2006-10-23 19:16
Message generated for change (Comment added) made by freddy77
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=407808&aid=1583025&group_id=33106
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: odbc
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Dave Gray (yargevad)
Assigned to: Nobody/Anonymous (nobody)
Summary: SQL Native Client compatibility updates
Initial Comment:
The attached patch was necessary when porting an
application written using SQL Native Client against MS
SQL Server 2005 to use unixODBC and FreeTDS.
----------------------------------------------------------------------
>Comment By: Frediano Ziglio (freddy77)
Date: 2007-04-06 11:10
Message:
Logged In: YES
user_id=75766
Originator: NO
Got no reply. I was unable to reproduce the problem
freddy77
----------------------------------------------------------------------
Comment By: Frediano Ziglio (freddy77)
Date: 2006-11-04 18:57
Message:
Logged In: YES
user_id=75766
Ok, I now understand but IMHO patch is not correct. Problem
raise cause we add a column without data so application try
to access not allocated data. However I was not able to
reproduce it. Also I don't understand why in this condition
you call _SQLExecute even if parameters are not sufficient...
Could you provide a small snippet to reproduce the segfault
or just some ODBC trace?
----------------------------------------------------------------------
Comment By: Dave Gray (yargevad)
Date: 2006-10-25 17:54
Message:
Logged In: YES
user_id=1628015
Looks like I didn't trim that patch enough, sorry about
that. There are only two FreeTDS pieces that make a
difference (see diff below). This updates FreeTDS to have
the same behavior as SQL Native Client when calling
SQLParamData even though there may not be more param data to
send. (As I understand it, SQLParamData is how to ask if you
need to send more data for other parameters.) The num_cols--
isn't skipping a column, it's preventing FreeTDS from trying
to look for a column that won't be there and segfaulting.
Index: src/odbc/prepare_query.c
===================================================================
--- src/odbc/prepare_query.c (revision 2687)
+++ src/odbc/prepare_query.c (revision 2735)
@@ -158,7 +158,7 @@
if (stmt->param_num >
stmt->apd->header.sql_desc_count
|| stmt->param_num >
stmt->ipd->header.sql_desc_count) {
/* TODO set error */
- return SQL_ERROR;
+ return SQL_SUCCESS_WITH_INFO;
}
switch (sql2tds
Index: src/odbc/odbc.c
===================================================================
--- src/odbc/odbc.c (revision 2687)
+++ src/odbc/odbc.c (revision 2735)
@@ -5242,10 +5242,13 @@
ODBC_RETURN(stmt, SQL_NEED_DATA);
}
++stmt->param_num;
switch (res = parse_prepared_query(stmt, 1)) {
case SQL_NEED_DATA:
*prgbValue =
stmt->apd->records[stmt->param_num - 1].sql_desc_data_ptr;
ODBC_RETURN(stmt, SQL_NEED_DATA);
+ case SQL_SUCCESS_WITH_INFO:
+ stmt->params->num_cols--;
case SQL_SUCCESS:
return _SQLExecute(stmt);
}
----------------------------------------------------------------------
Comment By: Frediano Ziglio (freddy77)
Date: 2006-10-25 10:30
Message:
Logged In: YES
user_id=75766
I don't understand what is intented to fix this patch. Could
you provide a brief test case or some lines of code that do
not works.
Looking at patch
@@ -216,6 +216,12 @@
case SQL_C_BINARY:
len = drec_apd->sql_desc_octet_length;
break;
+ case SQL_C_BIT:
+ len = 1;
+ break;
+ case SQL_C_LONG:
+ len = SIZEOF_LONG;
+ break;
case SQL_C_DATE:
case SQL_C_TYPE_DATE:
len = sizeof(DATE_STRUCT);
this should be handled by default case
@@ -278,6 +284,23 @@
if (sql_len < 0) {
/* test for SQL_C_CHAR/SQL_C_BINARY */
switch (sql_src_type) {
+ case SQL_C_DATE :
+ case SQL_C_TIME :
+ case SQL_C_TIMESTAMP :
+ case SQL_C_TYPE_DATE :
+ case SQL_C_TYPE_TIME :
+ case SQL_C_TYPE_TIMESTAMP :
+ dest_type = SQL_TYPE_TIMESTAMP;
+ break;
+ case SQL_C_NUMERIC:
+ dest_type = SQL_NUMERIC;
+ break;
+ case SQL_C_LONG:
+ dest_type = SQL_INTEGER;
+ break;
+ case SQL_C_BIT:
+ dest_type = SQL_BIT;
+ break;
case SQL_C_CHAR:
case SQL_C_BINARY:
break;
I really don't understand this code...
@@ -242,7 +242,7 @@
return SQL_ERROR;
if (stmt->param_num > stmt->apd->header.sql_desc_count ||
stmt->param_num > stmt->ipd->header.sql_desc_count)
- return SQL_ERROR;
+ return SQL_SUCCESS;
drec_apd = &stmt->apd->records[stmt->param_num - 1];
drec_ipd = &stmt->ipd->records[stmt->param_num - 1];
if param is not binded just ignore the param??
@@ -158,7 +158,7 @@
if (stmt->param_num > stmt->apd->header.sql_desc_count
|| stmt->param_num >
stmt->ipd->header.sql_desc_count) {
/* TODO set error */
- return SQL_ERROR;
+ return SQL_SUCCESS_WITH_INFO;
}
switch (sql2tds
...
@@ -5242,13 +5246,22 @@
ODBC_RETURN(stmt, SQL_NEED_DATA);
}
++stmt->param_num;
+
+ { int swiflag = 0;
+ SQLRETURN sret;
switch (res = parse_prepared_query(stmt, 1)) {
case SQL_NEED_DATA:
*prgbValue = stmt->apd->records[stmt->param_num -
1].sql_desc_data_ptr;
ODBC_RETURN(stmt, SQL_NEED_DATA);
+ case SQL_SUCCESS_WITH_INFO:
+ res = SQL_SUCCESS;
+ stmt->params->num_cols--;
+ swiflag=1;
case SQL_SUCCESS:
- return _SQLExecute(stmt);
- }
+ sret = _SQLExecute(stmt);
+ if (swiflag) stmt->params->num_cols++;
+ return sret;
+ }}
ODBC_RETURN(stmt, res);
}
Are you trying using one less parameter??
freddy77
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=407808&aid=1583025&group_id=33106
- [freetds] [ freetds-Patches-1583025 ] SQL Native Client compatibility updates, SourceForge.net, 04/06/2007
Archive powered by MHonArc 2.6.24.