mssql_odbc_multi_execute_patch.diff

--- ../ruby-odbc-0.9996/odbc.c	2009-02-02 12:06:38.000000000 -0600
+++ odbc.c	2009-03-12 11:43:38.000000000 -0500
@@ -166,6 +166,7 @@
     SQLSMALLINT ctype;
     SQLSMALLINT outtype;
     int outsize;
+    int biggestparam;
     char *outbuf;
 } PINFO;
 
@@ -3197,6 +3198,7 @@
 	pinfo[i].rlen = SQL_NULL_DATA;
 	pinfo[i].ctype = SQL_C_CHAR;
 	pinfo[i].outtype = SQL_CHAR;
+	pinfo[i].biggestparam = 0;
 	if (!succeeded(SQL_NULL_HENV, SQL_NULL_HDBC, hstmt,
 		       SQLDescribeParam(hstmt, (SQLUSMALLINT) (i + 1),
 					&pinfo[i].type, &pinfo[i].coldef,
@@ -6755,7 +6757,34 @@
 	    coldef = 19;
 	    break;
 	default:
-	    coldef = vlen;
+	    /*
+	    * Patch adopted from the Perl DBD::ODBC module...
+	    * 
+	    * per patch from Paul G. Weiss, who was experiencing re-preparing
+	    * of queries when the size of the bound string's were increasing
+	    * for example select * from tabtest where name = ?
+	    * then executing with 'paul' and then 'thomas' would cause
+	    * SQLServer to prepare the query twice, but if we ran 'thomas'
+	    * then 'paul', it would not re-prepare the query.  The key seems
+	    * to be allocating enough space for the largest parameter.
+	    * TBD: the default for this should be a DBD::ODBC specific option
+	    * or attribute.
+	    */
+	    if((stype == SQL_VARCHAR) && (q->pinfo[pnum].iotype != SQL_PARAM_INPUT_OUTPUT) &&
+               (q->pinfo[pnum].iotype != SQL_PARAM_OUTPUT)) {
+ 		if (q->pinfo[pnum].biggestparam == 0) {
+		    q->pinfo[pnum].biggestparam = (vlen > 80) ? vlen : 80;
+		} else {
+		/* bump up max, if needed */
+		    if (vlen > q->pinfo[pnum].biggestparam) {
+			q->pinfo[pnum].biggestparam = vlen;
+		    }
+		}
+                coldef = q->pinfo[pnum].biggestparam;
+	    }
+	    else {
+		coldef = vlen;
+	    }
 	    break;
 	}
     }