Connecting to ASE 15.7 from Windows Server 2012

[Former Member]

I've written a web service that connects to and ASE and creates some data. It works fine when deployed to Windows 7 or Windows Server 2008 R2 but not on Windows Server 2012.

Here's the error...

System.Data.EntityException: The underlying provider failed on Open. ---> Sybase.Data.AseCleint.AseException: Could not load code page for requested charset.

After googling I found some folks setting the charset in the connection string. I tried that and it worked! My question is why do I have to do that for Windows Server 2012?

Environment is the following...

Windows Server 2012 R2 Standard

IIS 8.5

ASE PC Client 15.7.0.130000

EntityFramework 5.0

Thanks,

Mark

[dawn_kim · Accepted solution]

Hi,

I wonder if one setting is different with one machine than the other. Do you know the machine is set to UTF8Encoding or UnicodeEncoding?

Could it be IIS 8.5 has a different code page setting?
ASP <asp> : The Official Microsoft IIS Site

Thanks,
Dawn Kim

[Former Member · Accepted solution]

Hi Dawn,

I installed the ASP module on both the Windows Server 2008 R2 and Windows Server 2012 boxes. The ASP code page value is 0 on both. The encoding values are Windows-1252 for file on both and utf-8 for request and response on both. I tried setting the code page to 28591 and removing the charset from the connection string but that didn't work.

I'm not any closer to finding a reason for this discrepancy between 2008 and 2012 but at least I know how to find and set the code page and encoding values in IIS thanks to you.

Mark

[dawn_kim · Accepted solution]

Hi Mark,

We had new feature, I wonder if it has something to do with it.

New Feature in SDK 15.7 SP100 - WindowsCharsetConverter

default is 0 to use unlib library.

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc20155.1570127/doc/html/ad...

I am wondering if you add this to your connection string and set it to 1. Do not add charset of change the charset in the connection string.

Thanks,
Dawn Kim

[Former Member · Accepted solution]

I tried that and it didn't work.

[dawn_kim]

Hi Mark,

On your other boxes do you have SDK installed on them?
On this 2012 box did you just deploy the package without installing the SDK?

Thanks,
Dawn Kim

[Former Member]

The 2008 box has the SDK and PC Client (15.5.0.1).

The 2012 box only has the PC Client (15.7.0.130).

Thanks!

[Former Member]

Hi Mark,

I believe this is a new cr I just logged for the drivers (ODBC and ADO.NET).  CR is 776257. On Windows 2012 and 8, the Open fails when connecting to certain ASEs with default charsets like cp850, cp437. We don't know why this happens but I escalated the CR.

What I found might work

Charset=ClientDefault

CodePageType=other

ClientCharset=iso_1  (or what you would like ASE to convert)

What is your default charset on ASE?

At this time since I just logged the CR I don't know the ETA.  Our next big SDK 15.7 release is SP133 due sometime in Q1. However, I don't think this CR will make the cut. At this time, let me know your ASE default charset and we can go from there.

An example is if ASE is cp850 and you set to iso_1, the driver will ask ASE to use iso_1 so it will convert cp850 chars to iso_1. The caveat here is some graphic chars in cp850 aren't mapped in iso_1 so there would be some issue there if that is the case.

Cheers,

-Paul

ASE Connectivity NEXUS, Support Architect

US AD&T Product Support

ADO.NET,ODBC, OLEDB, JDBC, ECDA, DC/MVS and more

ASE survey: https://www.sapsurvey.com/cgi-bin/qwebcorporate.dll?idx=WUUNJW

[Former Member]

Hi Paul,

Our default  charset appears to be cp850 using sp_helpsort. Thanks for initiating the ticket and your help with this. If there's anything else you want me to try let me know.

Mark

[Former Member]

Hi Mark,

I think you should try

Charset=ClientDefault

CodePageType=other

ClientCharset=iso_1

and test this if possible to make sure your conversions are okay. I don't see major issue - as mentioned I see some graphic chars not mapped to iso_1 which could be potential problem.

Cheers,

-Paul

[Former Member]

Sorry if this is a stupid question Paul but do you mean adding those settings to the connectstring?

[Former Member]

Hi Mark,

I am sorry - Yes - those are connection string properties to trick the driver so it will connect.

And there are no stupid questions!

Cheers,

-Paul

[Former Member]

Hi Paul,

Sorry for the delay. It looks like those settings worked too.

So now we have two work arounds:

1. Charset=iso_1

2. Charset=ClientDefault;CodePageType=other;clientCharset=iso_1

Where do we go from here?

Thanks,

Mark

[Former Member]

Hi Mark,

Sorry for late reply.  This is a known issue and ASE Driver Eng is aware of this and working on resolution to avoid use of the above work-arounds.  I have no ETA for this resolution at this time.

I don't know why it happens on newer Windows 2012/8 operating systems.  This is what we're trying to determine.

Hopefully, we'll have the fix in upcoming 15.7 release, eta is sometime in Q2 (tentative).

Cheers,

-Paul

[Former Member]

Hi Mark,

I tested this out again and found on my Windows 8 system I was testing that the SYBASE environment was messed up.  I had installed some product that set SYBASE variable but this product had no Connectivity - no interfaces file (sql.ini) and no charsets resource.

One of the reasons to get this error is if you deploy the Provider to the system without installing the SDK, the lack of charsets folder under the SYBASE root directory can cause this error to happen - so say for example ASE is cp850.  The Windows client is normally cp1252.  By default Provider connects to ASE to use cp850 as code page (charset) and without the resource in charsets for mappings, due to how the Provider handles conversions internally (it is natively Unicode internally) it's possible with the charsets resource the error occurs.

Now I know Windows 8 is different than Windows 2012.  But there shouldn't be significant changes in how to handle charsets unless, as stated, SYBASE\charsets is missing.  I have requested to integrate charsets into the DLL but this isn't looking to be happening.  However, one thing to try, if this description is the case is to create a SYBASE directory on the machine in question, copy charsets to it, set a SYBASE variable to the SYBASE directory created, then test Provider under this environment with default properties to see if this works.

At the least it would be an interim resolution.  If I find these types of issues keep happening I'll crank up the noise on the feature logged.  There is also possibility to provide some connection option to locate this charset resource on machine provided it is copied to the machine.  I don't have details yet on this until we complete implementation later this year.

Cheers,

-Paul