Re: locale problem

On Tue, Oct 05, 2011, Hamid A. Toussi wrote:
> Everything is working fine except in the case that we want to retrieve or
> manipulate non-English text (Farsi) in sql statements. 

1.  What goes wrong when you retrieve data?

2.  What is the output of locale(1) on the working and non-working systems?

3.  What iconv library, if any, are you using?  

4.  What encoding is used on the server?  Are these nvarchar (UCS2) data, 
    or varchar?  If varchar, what collation?  

5.  What endian is the ARM running?  

6.  What iconv messages do you see in each machine's TDSDUMP log?  
    
The purpose of these questions is to determine what FreeTDS is expected to do. 

It's possible your client and server are using exactly the same encoding, in
which case no conversion is needed.  The "no conversion" case should work if the
library recognizes server- and client-encodings as being the same.  It might
also "work" by accident if it does't recognize the charset name or can't find a
suitable conversion.  

If conversion is needed, you'll likely need GNU libiconv.  The built-in iconv
replacement library doesn't recognize any Farsi encoding.  

A final possibility is a bug in the built-in iconv.  If the data are nvarchar
and the client is utf8, the built-in iconv should work.  However, I'm not sure
how much it's been used with that combination on a big-endian machine.  So much
is little-endian these days, and Sparc users are usually ISO 8859-1.  

On Wed, Oct 05, 2011 at 11:03:09AM +0330, Hamid A. Toussi wrote:
> >
> > Can you try --enable-libiconv?
> >
> 
> When I try that I get the following error after running isql:
> isql: iconv.c:340: tds_iconv_open: Assertion `ret == 0' failed.
> Aborted

Look at your TDSDUMP log.  You'll see at least this message:

"error: tds_iconv_init() returned %d; "
"could not find a name for %s that your iconv accepts.\n"
"use: \"configure --disable-libiconv\"", ret, names[ret-1]);

You can ignore the advice to disable.  It will be interesting to see the 
other messages, though.  

HTH.

--jkl