Changes in monitoring tables - Firebird 3.0

[Tomasz Dubiel]

In Firebird 3.0 there were added to MON$ATTACHMENTS such columns as MON$REMOTE_HOST, MON$REMOTE_OS_USER.

Can be this a reason to such problem?: a customer had a Polish char (ł) in the computer name. On Firebird 2.5 it was not a problem, after moving to FB 3.0 he was no longer able to connect to the database with WIN1250 charset. He was getting an error:
"Invalid connection string Cannot transliterate character between character sets. Invalid or incomplete multibyte or wide character".

Is this expected or a bug? It was in our ERP system, as well in IBExpert.

[Omacht András]

Hi Tomasz,

 

we have a similar problem after converting from 2.5 to 3.0. Win1250 charset. So far, it has occurred on a single client's workstation. We couldn't figure out that the computer name could be causing the problem.

 

„Invalid connection string

Cannot transliterate character between character sets

Invalid or incomplete multibyte or wide character.

 

EIBInterBaseError: 335544972„

 

I asked the customer what the name of the machine is, I am waiting for his answer.

 

András

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/9cd5d06e-eae6-4747-911c-f63071130692n%40googlegroups.com.

[Dmitry Yemanov]

What's fbclient version used on that customer's host? 2.5 or 3.0?
What's the server platform and locale? Is it Linux with UTF8?


Dmitry

[Tomasz Dubiel]

It's Firebird 3.0.10. fbclient 3.0.8. It is Linux Debian. UTF8 - maybe, I would have to check.

[Omacht András]

Dmitry,

I got the answers to the questions:

Server: Linux, FB 3.0.10 release
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Client: Win, FB3.0.10

In our case "ó" is the problematic character in the windows' hostname

András

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/51e38169-23be-acf2-a709-2e55ff6b32e9%40yandex.ru.

[Dmitry Yemanov]

12.01.2023 22:43, Omacht András wrote:
>
> Client: Win, FB3.0.10
>
> In our case "ó" is the problematic character in the windows' hostname

What's the hostname length?


Dmitry

[Tommi Prami]

We had a similar case on a Windows environment where a customer had Å in the computer name. 

Tried various ways to reproduce the situation, but could do it on the console/terminal/command line. But not on Win10 interface, old Control panel or on Powershell. All those 3 reduced to using that character.

-Tee-

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/1ed2d4f5-cacc-645a-1c2a-85a39da69149%40yandex.ru.

[Karol Bieniaszewski]

This is why there is something like best practices:

1. Do not use spaces in folder names.
2. Do not use national characters in folder names
3. Do not use national characters in Windows user names.

 

And this advice is not for Firebird but all applications. If you like to have problems you can ignore such rules.

Of course fixing applications still should be the goal.

 

Regards,

Karol Bieniaszewski

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/CABwd-araiZLo7XxZUk_Zp_1p3mJW3%3Dt3vOkvkHv-XeDNSajqaQ%40mail.gmail.com.

 

[Karol Bieniaszewski]

Forgot to add

4. Do not use spaces and national characters in computer name or wifi SID.

 

But you catch the pattern i suppose.

 

Regards,

Karol Bieniaszewski

 

Od: Karol Bieniaszewski
Wysłano: piątek, 13 stycznia 2023 08:44
Do: firebird...@googlegroups.com
Temat: ODP: [firebird-support] Changes in monitoring tables - Firebird 3.0

 

This is why there is something like best practices:

1. Do not use spaces in folder names.
2. Do not use national characters in folder names
3. Do not use national characters in Windows user names.

 

And this advice is not for Firebird but all applications. If you like to have problems you can ignore such rules.

Of course fixing applications still should be the goal.

 

Regards,

Karol Bieniaszewski

 

Od: Tommi Prami
Wysłano: piątek, 13 stycznia 2023 08:33
Do: firebird...@googlegroups.com

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/CABwd-araiZLo7XxZUk_Zp_1p3mJW3%3Dt3vOkvkHv-XeDNSajqaQ%40mail.gmail.com.

 

 

[Omacht András]

Ten characters.

Pócsi Imre

András


-----Original Message-----
From: firebird...@googlegroups.com <firebird...@googlegroups.com> On Behalf Of Dmitry Yemanov
Sent: Friday, January 13, 2023 8:08 AM
To: firebird...@googlegroups.com
Subject: Re: [firebird-support] Changes in monitoring tables - Firebird 3.0

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/1ed2d4f5-cacc-645a-1c2a-85a39da69149%40yandex.ru.

[Tomasz Dubiel]

In our case 13, and the Polish char (ł) was the 4th char.

[Mathias Pannier (unitel)]

Note this is a bit off topic, but I disagree with 1.

In 1995 maybe it was a best practise but Windows itself uses spaces In folder names:

C:\Program Files (x86)

And every software in 2023 should work with this folder names.

 

Regards

Mathias

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/4NtYNR1S08zlhcGF%40smtp.poczta.onet.pl.

ub.unitel GmbH, Schulstraße 16, 06792 Sandersdorf-Brehna
Geschaeftsfuehrung Klaus Richter, Olaf Meyer
Amtsgericht Stendal
HRB 26389 FA Bitterfeld Steuernr. 116/107/08597 Ust.identNr. DE815796778
Deutsche Bank IBAN DE53 86070024 0 6143234 00
Kreissparkasse Anhalt-Bitterfeld IBAN DE69 80053722 0 3050326 82
_____________________________________________________________________
Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet
ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs-
äußerung ist die des Autors und stellt nicht notwendigerweise die
Ansicht oder Meinung von ub.unitel GmbH dar.
Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich
erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung,
Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt.
_____________________________________________________________________

[Tomasz Dubiel]

I created an issue:
https://github.com/FirebirdSQL/firebird/issues/7448

[Karol Bieniaszewski]

The rule 1 is still valid. And even if there is something like

C:\Program Files (x86)

you do not need to install applications there. We do not install there, only in cutom folder “C:\App\”.

And do not encoutered any problems for years. Also remember that if you install in  C:\Program Files (x86)

And some application add something to env vars you reach sonner or later another problem like too long env vars….

So we have short „App” folder name 😊

 

But this is only advice and something liek best administration practices if you have a good day without problems 😉

 

Regards,

Karol Bieniaszewski

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/abde94bccf6b4224a882acab016907be%40NT-Server11.unitel.lokal.

 

[Dimitry Sibiryakov]

Mathias Pannier (unitel) wrote 13.01.2023 9:03:
> In 1995 maybe it was a best practise but Windows itself uses spaces In folder names:
>
> C:\Program Files (x86)
>
> And every software in 2023 should work with this folder names.

Yes but the way they did it opened a door for viruses that put themself to
c:\Program.exe and get run every time when somebody is trying to run anything
from "Program Files". What is worse - it is documented on MSDN.

--
WBR, SD.

[Mark Rotteveel]

Maybe the problem is transliterating characters to the connection
character set, when the connection character set doesn't contain said
character?

Mark
--
Mark Rotteveel

[Dmitry Yemanov]

13.01.2023 13:34, Mark Rotteveel wrote:
>
>> What's fbclient version used on that customer's host? 2.5 or 3.0?
>> What's the server platform and locale? Is it Linux with UTF8?
>
> Maybe the problem is transliterating characters to the connection
> character set, when the connection character set doesn't contain said
> character?

No, connection charset should not matter here.

Hostname is sent by the remote protocol inside the CNCT_host tag of the
p_cnct_user_id. Starting with p_cnct_cversion == 3 all strings inside
p_cnct_user_id are converted (system->UTF8) before being transmitted.
The server side converts them back to the system locale (for
p_cnct_cversion == 3 only) and then again to UTF8 (for all versions), so
that everything inside the engine should be in UTF8. For Linux this
should be trivial as both input and system locale are UTF8. However, the
mentioned error is thrown by iconv() on the Linux side and I still don't
understand why. I failed to reproduce it on my side (Windows with a
WIN1251 hostname and Linux with UTF8 locale).


Dmitry

[Dimitry Sibiryakov]

Dmitry Yemanov wrote 13.01.2023 12:22:
> Starting with p_cnct_cversion == 3 all strings inside p_cnct_user_id are
> converted (system->UTF8) before being transmitted.

It better to use unicode functions to get the name from system and convert
wchar->UTF8.

> However, the mentioned error is thrown by iconv() on the Linux side and I still don't understand why.

No, it can be a local error thrown by ISC_systemToUtf8.

> I failed to reproduce it on my side (Windows with a WIN1251 hostname and Linux with UTF8 locale).

It is not clear which code page was set as ANSI in original message and if
mentioned "ł" exists there. In 1250 it is but in 1252 - isn't.

--
WBR, SD.

[Dmitry Yemanov]

13.01.2023 14:47, 'Dimitry Sibiryakov' wrote:

>> Starting with p_cnct_cversion == 3 all strings inside p_cnct_user_id
>> are converted (system->UTF8) before being transmitted.
>
> It better to use unicode functions to get the name from system and
> convert wchar->UTF8.

Maybe, but the current approach (ANSI->wchar->UTF8) should not hurt either.

>> However, the mentioned error is thrown by iconv() on the Linux side
>> and I still don't understand why.
>
>   No, it can be a local error thrown by ISC_systemToUtf8.

AFAIK, "Invalid or incomplete multibyte or wide character" is a Linux
specific error message.


Dmitry

[Dimitry Sibiryakov]

Dmitry Yemanov wrote 13.01.2023 14:03:
> AFAIK, "Invalid or incomplete multibyte or wide character" is a Linux specific
> error message.

Then I see two possibilities:

1. Client sends somehow truncated or padded with garbage string.
2. Locale for Firebird server process on Linux is set to default "C" instead of
"UTF-8".

--
WBR, SD.

[Dmitry Yemanov]

13.01.2023 17:13, 'Dimitry Sibiryakov':

>
>   Then I see two possibilities:
>
> 1. Client sends somehow truncated or padded with garbage string.

The question is "how"...

> 2. Locale for Firebird server process on Linux is set to default "C"
> instead of "UTF-8".

#ifdef HAVE_LOCALE_H
// Pick up the system locale to allow SYSTEM<->UTF8 conversions
inside the engine
setlocale(LC_CTYPE, "");
#endif

and the reported

LC_CTYPE="en_US.UTF-8"

make this possibility virtually impossible...


Dmitry

[Tomasz Dubiel]

Reproducing the bug should not be difficult. You would have to change the Windows language to Polish for example, set any computername with one of "ąśćężźółń" :-), and connect to the database on Linux with WIN1250.

[Dmitry Yemanov]

13.01.2023 17:54, Tomasz Dubiel wrote:

> Reproducing the bug should not be difficult. You would have to change
> the Windows language to Polish for example, set any computername with
> one of "ąśćężźółń" :-), and connect to the database on Linux with WIN1250.

Just did exactly what you say and still can connect successfully. Sigh.


Dmitry

[Dimitry Sibiryakov]

Dmitry Yemanov wrote 13.01.2023 15:41:
> and the reported
>
> LC_CTYPE="en_US.UTF-8"
>
> make this possibility virtually impossible...

Reported for user session. Firebird server can have completely different
environment.

--
WBR, SD.

[Tomasz Dubiel]

Could you tell us what exact version of Linux it was? Maybe the problem is with the exact systems.

For us it occured twice: first it was on very old Linux, Debian 6.0.2, and second on not so old Debian 9.13

[AlexPeshkoff]

May be client OS is using OEM codepage but fbclient tries to interpret it as ANSI? In that case server receives wrong UTF-8 character and reports it.

суббота, 14 января 2023 г. в 20:47:27 UTC+3, tkdu...@gmail.com:

[Omacht András]

Hi Tomasz,

 

I got the information:

 

Linux L01 4.9.0-12-amd64 #1 SMP Devuan 4.9.210-1 (2020-01-20) x86_64 GNU/Linux

Distributor ID:    Devuan
Description:    Devuan GNU/Linux 2.1 (ascii)
Release:    2.1
Codename:    ascii

as I see it is a Debian Stretch (9.x) fork.

 

András

To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/23ccac38-618a-4802-a98f-0db25cabcfb5n%40googlegroups.com.