Scott Nichols - 2006-04-13

Logged In: YES
user_id=787831

I also noticed when testing the SQL prepared statement
with the tclodbc package that it didn't handle empty
strings correctly. I was able to help another Tcl ODBC
package snodbc with the fix. See below. You'll need to
edit the C sources. Basically when you do your SQL_Bind
you'll need to add one to the buffer if the Tcl string is
a blank string.

I fixed a bug in my copy of snodbc when using it with SQL
prepared statements. The bug has to do with using blank
Tcl data (like set myvar {}) in SQL prepared statements. I
guessed where to fix it in the code but it works. I
recommend the snodbc author double-check my new way snipit
below. FYI... The original tclodbc package suffers from
the same problem, but I don't have the C++ sources it fix
it too. Here's what I changed in snodbc's odbc-obj.tcl
package script to make prepared statements work with blank
varchars passed from Tcl:

# snODBC Packa Old Way (find this line in odbc-obj.tcl)
if {!$pprec} { set pprec $charlen}
set bound [SQLBindParameter $hstmt $ip 1 $c_type $ptype
$pprec $pscale [::ffidlx::buffer addr $buf] [string
length $bytes] [expr {$theIndicator+$pib}]]

# snODBC Package New Way
if {!$pprec} { set pprec [expr {$charlen + 1}]}
set bound [SQLBindParameter $hstmt $ip 1 $c_type $ptype
$pprec $pscale [::ffidlx::buffer addr $buf] [expr
{[string length $bytes] + 1}] [expr {$theIndicator+$pib}]]

In the latter snipit, I simply increased the allocated SQL
buffer by one to handle blank Tcl data. This shouldn't
hurt anything that I know of. Another way to code it would
be to first check if the length of the Tcl var was zero
then add one if it is.