FreeTDS Development Group

["FlavianoMa" <FlavianoMa.software AT teseo.com>]

If you want to apply my patches you need only to use the 2 files attached 
with the previuos msg and after look in the header of file UNICODE.C to see 
what other files need to copy from GNU libiconv library.
I can't use the all GNU libiconv library because it is 900kb and I don't have 
so free space,  and I think that the results it will be the same.
The columns in the server is nvarchar.

I found the solution: add the N char before any string of statements.
I use the DB-Library of FreeTDS to connect with SQL server 2000.
I found in the documentation of Microsoft "The ODBC (version 3.6 or earlier) 
and the DB-Library APIs do not recognize Unicode" 
And after... "Unicode string constants that appear in code executed on the 
server, such as in stored procedures and triggers, must be preceded by the 
capital letter N. Without the N prefix, the string is converted to the 
default code page of the database, which may not recognize certain 
characters."

So I tried to use :
UPDATE PATTERNS SET T_NAME=N'<unicode string>' WHERE K_PATTID=1
It works!
So now I need only to change in my program all  

='%s'    

in

=N'%s'

So any Unicode string is correctly read from the Server.
Do you think it is the right solution?

Thanks
Flaviano

> -----Messaggio originale-----
> Da: freetds-bounces AT lists.ibiblio.org 
> [mailto:freetds-bounces AT lists.ibiblio.org] Per conto di 
> Lowden, James K
> Inviato: venerdì 6 maggio 2005 19.36
> A: FreeTDS Development Group
> Oggetto: RE: [freetds] Charset conversion Polish
> 
> > From: FlavianoMa
> > Sent: Thursday, May 05, 2005 1:31 PM
> > 
> > In my system is not available the iconv library, so I modified the 
> > built-in iconv substitute in FreeTDS to accept different charset ( 
> > CP1250, CP1254, CP1256, CP1251 ).
> 
> My, my.  I'd be interested in applying your patches, if you'd 
> like to contribute them.  But you really wouldn't have needed 
> to do all that work if you'd installed the GNU libiconv library.  

 
> > Now when I read
> > data from the SQL Server I receive data correctly.  When I write on 
> > the server, I write the correct Unicode buffer ( I checked on 
> > freetds.log), but the server convert my character before 
> save on DB, 
> > so after if I'll read the same buffer it will be different 
> ( checked 
> > on freetds.log).
> 
> I think this is what's happening: you write UCS-2 data to the 
> server, to be inserted in a column with a datatype of char, 
> varchar, or text -- a single-byte encoding.  Depending on the 
> server version, the character set of a column is defined by 
> server or (in 2000) by column.  The server obviously can't 
> store your UCS-2 data in a  varchar column verbatim, so it 
> converts it to the encoding defined for that column.  When 
> you then SELECT the same data from the table, you find it's 
> not encoded "correctly" i.e., not according to the client's charset.  
> 
> With FreeTDS 0.63 and a complete iconv implementation, even 
> the above scenario should work.  When you SELECT the data, it 
> comes labelled with its encoding (determined at login with 
> TDS 7.0, per resultset column with TDS 8.0).  FreeTDS 
> converts the data -- insofar as possible -- to the client's 
> encoding as specified in freetds.conf.  
> 
> Assuming I'm right, you have these choices:
> 
> 1.  Use nchar, nvarchar, or ntext columns.  Then the server 
> can store your USC-2 data without conversion.  
> 
> 2.  Match your server's encoding to the client.  
> 
> 3.  Use GNU iconv.  
> 
> For the record, Microsoft servers never convert encodings 
> headed for the client.  They expect their clients to support 
> UCS-2 and to be configured with the same charset used by the server.  
> 

Flaviano Maricotti
Software Department

----------------------------------------------------------------------------------------------
 
TESEO spa  via Agnelli 49  63023 FERMO (AP) ITALY   Tel. +39 0734 628818  
Fax. +39 0734 628816

software AT teseo.com      FlavianoMa.software AT teseo.com


DISCLAIMER. This electronic mail transmission may contain legally priviledge 
and/or confidential information. Do not read this if you are not the 
person(s) named.  Any use, distribution, copying or disclosure by any other 
person is stricly prohibited. If you received this trasmission in error 
destroy the original transmission and its attachments without reading or 
saving in any manner.
----------------------------------------------------------------------------------------------