FreeTDS Development Group

["ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>]

> 
> I'm using Ruby/ODBC with FreeTDS (connecting to a MSSQL server), and 
> I've discovered a bug. The only problem is, I'm having difficulty 
> determining whose bug it is...
> 
> Here's some code:
> 
>    require 'odbc'
> 
>    db = ODBC::connect("sedev", "", "")
>    db.do("DROP TABLE test") rescue nil
>    db.do("CREATE TABLE test (tid INTEGER IDENTITY, thing INTEGER)")
>    db.do("INSERT INTO test (thing) VALUES (1234)")
>    db.do("INSERT INTO test (thing) VALUES (?)", 1234)
>    s = db.run("SELECT * FROM test")
>    while(row = s.fetch)
>      p row
>    end
>    s.drop
> 
> Output:
> 
>    ntalbott@proxytest:~/cvs/se-2/se/src$ ruby t2.rb
>    ["1", 1234]
>    ["2", 1]
> 
> (If you want to get your hands on Ruby/ODBC, check out 
> http://www.ch-werner.de/rubyodbc/. I'm actually using a newer, 
> pre-release version, but I don't think anythings changed that affects 
> this problem.)
> 
> The issue centers around FreeTDS not supporting 
> SQLDescribeParam. This 
> is valid, and Ruby/ODBC simply marks the parameter as SQL_VARCHAR. So 
> far so good. Next Ruby/ODBC sees that the type being bound to the 
> column is a (Ruby) integer, and so it marks the C type of the 
> parameter 
> as SQL_C_LONG. That should be right, too. Then Ruby/ODBC sets 
> to 1 the 
> StrLen_or_IndPtr argument (FreeTDS names the argument pcbValue) of 
> _SQLBindParameter. The issue seems to be that FreeTDS (or MSSQL?) 
> truncates the value based on this last argument after casting from a 
> SQL_C_LONG to a SQL_VARCHAR. Meaning I end up with 1 instead of 1234.
> 
> The question is, is Ruby/ODBC wrong to set the length to 1? Or is 
> FreeTDS wrong to use that value and truncate the value. I'm leaning 
> towards the latter, but I'm having difficulty figuring out 
> where to fix 
> FreeTDS.
> 
> Any ideas? I can give you a TDSDUMP if that would help.
> 
> Thanks,
> 
> 
> Nathaniel
> 

Hi Nathaniel!

Yes, this can be true. Your description is very accurate. Ruby is
correct, FreeTDS not, ODBC should ignore length if SQL_C_LONG is used.
Can you send please TDSDUMP and ODBC trace? 
However I think your problem is related to 0.61 version that converts
always prepared statement in sql statements, the problem should not
occour in CVS version. If you are using Linux/FreeBSD (that contain good
iconv library) can you test with snapshot?

freddy77