FreeTDS Development Group

[Jos.van.Santen AT rabobank.nl]

Hi community,

I kindly call upon your knowledge about the issue we are facing and mentioned 
below.

Does anyone have a clue?

Thanks in advance.

Jos

> -----Oorspronkelijk bericht-----
> Van: FreeTDS [mailto:freetds-bounces AT lists.ibiblio.org] Namens Santen van,
> JDG (Jos)
> Verzonden: maandag 22 augustus 2016 12:44
> Aan: FreeTDS Development Group
> Onderwerp: Re: [freetds] diacritics issue
> 
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: FreeTDS [mailto:freetds-bounces AT lists.ibiblio.org] Namens
> > Frediano Ziglio
> > Verzonden: zaterdag 20 augustus 2016 10:26
> > Aan: FreeTDS Development Group
> > Onderwerp: Re: [freetds] diacritics issue
> >
> > 2016-08-18 7:28 GMT+01:00 Santen van, JDG (Jos)
> > <Jos.van.Santen AT rabobank.nl>:
> > > Hi
> > >
> > > I am facing an issue with diacritics.
> > > I am running MS SQL Enterprise x64 version 11.0.6523.0, created a
> > > table there with a colomn type varchar(100) and nvarchar(100) Stored
> > > the
> > string: 蚞ȊŽàâçèéêëîïôùûüÀÂÇÈÉÊËÎÏÔÙÛÜáíóúñÁÍÓÚÑäöÄÖğışĞIŞ in
> both
> > fields.
> > >
> > > Codepage is 1252 latin and server collation is Latin1_General_CI_AS
> > > The table is using the servers defaults.
> > >
> >
> > č and Č are not available in Windows 1252 encoding.
> > Same for ğ, ı, ş, Ğ and Ş.
> 
> Correct, but they are perfectly converted to their ascii equivalent c, C, 
> g, i G
> and S.
> 
> >
> > > Using FreeTDS driver 0.91, defined protocol version 7.0 in the
> > > freetds config, the data retrieved by the client is corrupted, the
> > > šž  (9a 9e) and ŠŽ (8a 8e) aren’t viewable in our client and returned
> ‘blanks’
> > > (actually the 9a 9e and 8a 8e aren’t visible in our client), the
> > > ğışĞIŞ is returned as gisGIS (67 69 73 47 49 53)
> > >
> >
> > Maybe your client is not correctly. 9a 9e is the right encoding for
> > windows 1252.
> > Which client encoding are you using?
> 
> The client uses UCS2 encoding.
> 
> > FreeTDS 0.91 is quite obsolete.
> > Which library are you using?
> 
> Currently we use UnixODBC 2.2.14
> 
> >
> > > The returned hex values of the complete string for both field types
> > > is the
> > same:
> > > 63 9a 9e 43 8a 8e e0 e2 e7 e8 e9 ea eb ee ef f4 f9 fb fc c0 c2 c7 c8
> > > c9 ca cb ce cf d4 d9 db dc e1 ed f3 fa f1 c1 cd d3 da d1 e4 f6 c4 d6
> > > 67 69 73 47 49 53
> > >
> >
> > From the log/server or from the library you are using?
> >
> > > A part of the debug log related to character conversion:
> > > iconv.c:330:tds_iconv_open(0x1891400, UTF-8) iconv.c:187:local name
> > > for ISO-8859-1 is ISO-8859-1 iconv.c:187:local name for UTF-8 is
> > > UTF-8 iconv.c:187:local name for UCS-2LE is UCS-2LE
> > > iconv.c:187:local name for UCS-2BE is UCS-2BE iconv.c:349:setting up
> > > conversions for client charset "UTF-8"
> > > iconv.c:351:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion
> > > iconv.c:391:preparing iconv for "ISO-8859-1" <-> "ISO-8859-1"
> > > conversion
> > > iconv.c:394:tds_iconv_open: done
> > > net.c:205:Connecting to x.x.x.x port 1433 (TDS version 4.2)
> > >
> > > (btw: Notice the TDS version used: 4.2 while we defined 7.0)
> > >
> >
> > It seems you are really using 4.2. How did you defined 7.0 ?
> 
> In the config file for this datasource we defined:  tds version = 7.0
> 
> >
> > > Does anyone know how to solve this issue?
> > >
> > > BR Jos
> >
> > Frediano
> 
> BR Jos
> ======================================================
> Rabobank disclaimer: http://www.rabobank.nl/disclaimer
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
======================================================
Rabobank disclaimer: http://www.rabobank.nl/disclaimer