Brainstorming about ClientCodePage

[aehimself]

Yesterday when I was travelling home from work I started to think. ClientCodePage defines in what encoding strings arrive from the database (which at the end gets converted to Unicode). This is clear until now.

Let's say I have an application to store books, accessing the data with ZQuery.FieldByName('field').AsString. Only one application is accessing this database, not cross platform, no DB "hacking" with management applications (should ) happen.
This application has a config file to store the database properties. User name, host name, password, etc.

And now to the real question. In this context, should we allow the user to change the ClientCodePage via the config file? I mean if data is only read and written to the database by this application and I keep the encoding on (protocol specific) UTF8, it should always work, no? In what scenarios NOT allowing changing the encoding can cause issues?

This is only a theoretical question, but any insight is appreciated

[Fr0sT]

I could seem rather radical but I'd say codepages are for legacy stuff only, modern stuff should use utf8 everywhere and forget about codepages at all

[aehimself]

@Frost, am I right to assume that you just confirmed my thought? In the above scenario - unless some unauthorized data modification happen - it must always work as planned? And finally I did not overlook anything?

[Fr0sT]

Unfortunately (or fortunately )) ) I've no experience in multi-language DB apps but I'm pretty sure than in modern world the real need in codepages is very very rare. So yes, I guess you're right