Den 2019-12-02 kl. 16:56, skrev Dimitry Sibiryakov [email protected] [firebird-support]: > 02.12.2019 16:35, Kjell Rilbe [email protected] > [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]
