FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Johnny Ljunggren [mailto:johnny AT navtek.no]
> Sent: May 12, 2003 11:48 AM
> 
> I have this system:
> MS SQL 2000 sp2, freetds-0.62.dev.20030508, unixODBC-2.2.5
> 
> I have made a small test database on the SQL-server:
>  DB name: JCTest
>  One table with name: text
>  One column with name: textcol
>  Datatype and length: nvarchar 20
> 
> One entry in the table:
>  textcol = 'Excellent test' 
> 
> If I run the isql-program that comes with unixODBC, I connect 
> OK and try this statement:
> select * from text;
> That should return 'Excellent test' but return this:
> +---------------------+
> | text                |
> +---------------------+
> |                     |
> +---------------------+
> 1 rows affected
> 1 rows returned
> 
> If I enter the same statement again I get this:
> [unixODBC]Changed database context to 'JCTest'.
> [unixODBC]Changed language setting to us_english.
> [unixODBC]Option not supported
> [ISQL]ERROR: Could not SQLExecute
> 
> If I change data type to 'char' or length to i.e. 50 then suddenly
> everything works as it should.
> 
> How is this possible? What do I do wrong?

Johnny, 

Welcome to the project and thanks for helping us straighten out charset
handling.  

What's odd about your test is that uses only ASCII characters (about the
easiest conversion possible) yet still fails.  It makes me wonder if
somewhere in the odbc library we might be returning zero for the data size
or something.  

> If I change data type to 'char' or length to i.e. 50 then suddenly
> everything works as it should.

Do you mean that nvarchar(20) fails but nvarchar(50) works?  Computers!
What will they think of next?  Does nvarchar(19) or nvarchar(21) work any
better?  

As Frediano suggested, please set the TDSDUMP variable and post the log,
taking care to remove any passwords.  The log will show us what client
character set FreeTDS is converting to, and should expose any conversion
errors.  

You might also try the same query in tsql.  If tsql works and isql does not,
it could be because isql isn't initializing the locale information.  Seems
unlikely, but a useful distinction; tsql cuts out several layers.  

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.