[freetds] Problems with nvarchar

Lowden, James K LowdenJK at bernstein.com
Mon May 12 12:33:59 EDT 2003

> 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?


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

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

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

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.  

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.

More information about the FreeTDS mailing list