cancel
Showing results for 
Search instead for 
Did you mean: 

Charset cp850 Sybase ASE - ADO.NET

Former Member
0 Kudos

Hi!

I am developing an asp.net mvc application that connects to Sybase. The data in the database are in Spanish, with accents and character 'ñ'. When I retrieve data through ado.net connection, these characters are not interpreted correctly. The connection to the database is:

<connectionStrings>

    <add name="database" connectionString="Data Source='192.168.0.1';Port='5000';UID='sa';PWD='';Database='test';CharSet='cp850';" />

</connectionStrings>

It is assumed that the charset that I use is cp850. The database by default uses this charset.

I have read that a user has used the connection parameter KeepOrgMultibyte=1, but does not work me.

Thank you for you help

Accepted Solutions (1)

Accepted Solutions (1)

dawn_kim
Contributor
0 Kudos

Hi,

So are you developing this on Windows 2012 or a different version of Windows? What version of the Sybase.AdoNet#.AseClient.dll are you using? I am assuming your ASE's default charset is CP850? What language is the ASE set to?

Please give us this information I think you might be hitting a known issue. If it is the issue than you might try to set the charset=iso_1.

Thanks,
Dawn Kim

Former Member
0 Kudos

Hi,

I'm developing on a Windows 7 Professional with Visual Studio 2012. I use Sybase Adaptive Server Enterprise Pc Client 15.0 (Sybase.Data.AseClient.dll, sybdrvado11.dll) as dataprovider.

Sybase configuration:

- Adaptive Server Enterprise 12.5.3

- Character set: Code Page 850 (Multilingual) character set

- Language: us_english

charset=iso_1 doesnt work. Same result that charset=cp850

Thanks,

Raul

dawn_kim
Contributor
0 Kudos

Hi,

I found this CR 397650 Ado.net character set conversion issues between cp850 and cp1252(windows) for ado.net driver fixed in SDK 15.0 ESD#2 which is Sybase.Data.AseClient.dll version 1.15.82.0.

I also so another issue if the ASE has 'enable Unicode normalization' =0. This was fixed in SDK 15.0. ESD#17 which is Sybase.Data.AseClient.dll version 1.15.346.0.

So right now my suggestion is to upgrade the driver to the Sybase.AdoNet2.AseClient.dll and use the later version.

If you upgrade the driver you might have to upgrade the oledb/adonet MDA scripts on the ASE to work correctly with newer driver. You can check the version by doing sp_version to the ASE if this comes back with.

Thanks,
Dawn Kim


Former Member
0 Kudos

I downloaded from SAP Store this software:

SDK for SAP Adaptive Server Enterprise 15.7 SP127 Windows Server on IA32 32 bit 22941

After installation, I have got two drivers:

Sybase.AdoNet2.AseClient.dll (version: 2.157.1300.0)

Sybase.AdoNet4.AseClient.dll (version: 2.157.1300.0)

I used the two drivers and special characters (for example: 'ñ') are not interpreted correctly. If I use the connection parameter 'KeepOrgMultibyte=1' it works, I don't understand!. Is it safe to use this parameter?


<connectionStrings>

    <add name="database" connectionString="Data Source='192.168.0.1';Port='5000';UID='sa';PWD='';Database='test';CharSet='cp850';KeepOrgMultibyte='1'" />

</connectionStrings>

Regards

Raúl

dawn_kim
Contributor
0 Kudos

Hi,

Okay, so this is the situation, you have a special character that is not part of the CP850 English charset. I am also assuming that this data is in a char or varchar column versus a unichar or univarchar column. The ASE is storing this as ??? or if you look at the binary it will 0A for the first digit since this is a character not of that charset.

For the driver to read it right you have to use KeepOrgMultibyte since the ASE has it stored funky.

It truly is a workaround until they upgrade the ASE to an appropriate charset or fix the column type. Usually this data is from years and years of information and it makes it hard for companies to change because the data needs to restored correctly, etc.
Since most companies are global you are more likely to see a utf8 charset as default now a days so you don't run into these issues. 

I am just glad upgrading the driver made it so you can at least use the workaround.

Thanks,
Dawn Kim

Former Member
0 Kudos

Hi Dawn,

Thanks for your answer

Regards,

Raúl

Answers (0)