AdoNetCore.AseClient.AseException: 'Server environment changed to unsupported charset '

[anawar82]

I get AdoNetCore.AseClient.AseException: 'Server environment changed to unsupported charset ' when trying to open the connection

[senseibaka]

Hi @anawar82,

Our driver throws this exception when the server tells it to use a charset it doesn't support. Usually this charset's name would appear at the end of the exception message (throw new AseException($"Server environment changed to unsupported charset {change.NewValue}");), so that's weird.

Can you tell me:

• What the charset of your database/server is?
• The content of your connection string?

Cheers

[anawar82]

Code Page 850 (Multilingual)

"SybConnectionString": "Data Source=10.1.254.254; Port=4000; Database=DB; UID=sa; PWD=XYZ; charset=cp850;"

I have also tried without mentioning the charset, and I get the same error.

On Oct 25, 2018, at 1:35 AM, Nicholas Sizer notifications@github.com wrote:

Hi @anawar82 https://github.com/anawar82,

Our driver throws this exception when the server tells it to use a charset it doesn't support. Usually this charset's name would appear at the end of the exception message (throw new AseException($"Server environment changed to unsupported charset {change.NewValue}");), so that's weird.

Can you tell me what the charset of your database/server is?

Cheers

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DataAction/AdoNetCore.AseClient/issues/89#issuecomment-432851668, or mute the thread https://github.com/notifications/unsubscribe-auth/AqLsqX5FQ3GMAQsit_Yg944G6L-duH11ks5uoOsmgaJpZM4X3c05.

[senseibaka]

Thanks @anawar82

So .net core does not natively support ibm850 (refer these msdn remarks). Therefore, the driver in its current state also doesn't support ibm850.

There are a couple of options as to how support could be added to the driver:

1. Implement an EncodingProvider within the driver's code.
2. Leverage the System.Text.Encoding.CodePages nuget package - see https://stackoverflow.com/a/37870346/242311

I'm not entirely happy with either option, in particular:

• Implementing an EncodingProvider seems like a waste when probably someone has already implemented it, and it feels like implementing any text encoding is outside the domain of this driver's purpose. In short, it feels a bit "bloaty" to add it.
• I'm reluctant to add another dependency to the driver. Ideally I would like it to remain relatively lean.

However, the above does not help you use the driver, so here's a third option which might help us both:

• Add to the driver implicit support for as many of the charsets as possible, and leave it to the consumer to register their own EncodingProvider (either by implementing one, or adding an appropriate project reference).
• Add some documentation to this GitHub project explaining how to add non-standard charset support.

Would you be happy with that solution?