Re: [firebird-support] Fail to create external table
Den 2019-12-02 kl. 16:56, skrev Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]: > 02.12.2019 16:35, Kjell Rilbe kjell.ri...@marknadsinformation.se > [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]
Re: [firebird-support] Fail to create external table
02.12.2019 16:35, Kjell Rilbe kjell.ri...@marknadsinformation.se [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. -- WBR, SD. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
[firebird-support] Fail to create external table
Hi,
Using Firebird 3.0.4.33054 on WIndows (64 bit), I want to create an
external table where the external file name contains Swedish letters. I
would think this is a reasonable desire these days.
After failing to get the character encoding right in FlameRobin, I
thought I'd try isql.exe.
So I fired up a command prompt, set codepage to UTF-8 (chcp 65001). Then
connected to my database in isql and did a select to check that it
indeed does display existing UTF-8 data correctly, to ensure that I
actually got the connection character set right. Seems to work.
Then I try this SQL:
create table "ExSlask" external file 'D:\MISE\Data\Firebird\Teståäö.txt'
("Id" char(5) character set win1252, "CRLF" char(2) character set win1252);
When I press enter, isql.exe exits without any message whatsoever. I'm
just returned to the Windows command prompt. No external table is created.
Any ideas?
The same SQL executes fine in FlameRobin, but the resulting file name is
"Teståäö.txt", which means that FlameRobin and/or Firebird fails to
correctly convert the UTF-8 encoded string in the SQL into the file
system's encoding (Win1252). I have FlameRobin connected using UTF-8
connection charset.
Mvh,
Kjell
[Non-text portions of this message have been removed]
