Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Garbage with e.g. umlauts in the raw trace output [CORE3280] #3648

Open
firebird-automations opened this issue Dec 15, 2010 · 2 comments
Open

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Thomas Steinmaurer (tsteinmaurer)

Hello,

in a Firebird 2.5 database created with ISO8859_1 and also using ISO8859_1 at connect time, I get the following in fsql:

SQL> select 'ä' from rdb$database;

CONSTANT

ä

But the raw output of a trace session gives me:

2010-11-19T11:02:11.6010 (4588:00000000011ABAE0) START_TRANSACTION
tourism.fdb (ATT_1437, TOURISM:NONE, ISO88591, TCPv4:127.0.0.1)
C:\Program Files\Firebird\Firebird_250_3051\bin\fsql.exe:5280
(TRA_24528, CONCURRENCY | WAIT | READ_WRITE)

2010-11-19T11:02:11.6020 (4588:00000000011ABAE0) EXECUTE_STATEMENT_START
tourism.fdb (ATT_1437, TOURISM:NONE, ISO88591, TCPv4:127.0.0.1)
C:\Program Files\Firebird\Firebird_250_3051\bin\fsql.exe:5280
(TRA_24528, CONCURRENCY | WAIT | READ_WRITE)

Statement 1906:
-------------------------------------------------------------------------------
select '„' from rdb$database
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$DATABASE NATURAL)

I don't see the 'ä' correctly. So, are there any problems dealing with special (Non-Ansi?) characters in the raw trace data output?

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

What is real encoding used in fsql session ? Is it used OEM codepage as usual console application ?

Trace does not perform conversion of characters of users strings (queries, parameters, etc). So, in general,
yes, we have a problem - trace output with data from different users connections could contain strings in
different encodings.

We can convert all this pieces into UTF8, i think, and have consistent trace output, but it will cost us some
performance penalty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants