FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il lun, 2003-05-12 alle 20:37, Johnny Ljunggren ha scritto:
> On Mon, 12 May 2003 12:33:59 -0400
> "Lowden, James K" <LowdenJK AT bernstein.com> wrote:
> 
> > > I have this system:
> > > MS SQL 2000 sp2, freetds-0.62.dev.20030508, unixODBC-2.2.5
> > > 
> <snip DB-setup>
> > > 
> > > 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
> > > 
> >
> > Welcome to the project and thanks for helping us straighten out charset
> > handling.  
> 
> Thanks. Hopefully you can help me as well :)
>  
> > > 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?  
> 
> For this test the critical value seems to be 40. ie 39 doesn't work, but
> 40 does. And this is repeatable.
>  
> > 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.
> 
> I'm unable to use this. It seems to log in, but does not return any data.
> locale is "no_NO"
> charset is "ISO-8859-1"
> Password:
> Msg 5703, Level 0, State 1, Server PIMS, Line 0
> Changed language setting to us_english.
> 1> select * from text;
> 2> select * from tt;
> 3>

Fixed in CVS. Problem was caused by a test overflow test from server. 
>From 0.60 version a test to detect columns larger than expected (like
'test' returned for a char(2), where server try to cause a buffer
overflow on client). Previous version computed client size for
n(var)char doing a simple (/2) division. Now we can't compute client
size directly so division has been removed. So returning 'Excellent
test' return more than 20 bytes causing error...

Now tds_get_char_data do the right job (well, it's expected to do it
...)

freddy77

PS: I'll add a test for this problem...