Den 2019-12-02 kl. 16:56, skrev Dimitry Sibiryakov sd@...
[firebird-support]:

> 02.12.2019 16:35, Kjell Rilbe kjell.rilbe@... [firebird-support] wrote:
>> Any ideas?
> In short: give up. Just give up.
> In long: both client side and server side ANSI code pages must support these letter.

They do. All involved operating systems use Windows-1252.

I realized now that I failed to actually set the connection charset for
the isql session.

I tried now with "chcp 1252" then start isql.exe and before connect
issue "set names win1252;" command. In that state, I was able to select
existing UTF-8 data and get it properly translitterated in the isql session.

In this state, I tried again to create the external table, and again got
the file name "Teståäö.txt" which is the Win1252 interpretation of
"Teståäö.txt" in UTF-8 encoding.

In other words, it would seem that isql.exe correctly transliterated my
win1252 encoded input string "Teståäö.txt" and sent it to the server
that way. The server database character set it UTF-8, so I suspect that
the server then transliterates the file name into an UTF-8 string and
passes that to the file system using an non-unicode API call, that would
then expect the string to be encoded with the operating system's code
page, in this case Windows-1252. I think that's where the error occurs.

Should I report this as a bug? I.e. that Firebird server engine fails to
transliterate the file name for an external table from the database
character set into the OS character set when making OS API calls for the
corresponding file operations.

Regards,
Kjell




[Non-text portions of this message have been removed]