Firebirdforum.de

Hallo.

ISQL Version: LI-T4.0.0.1436 Firebird 4.0 Beta 1
Linux Mint v19.3
GNOME-Terminal v3.28.1

Ich stelle sowohl zwei Terminal-Sitzungen (adressen.fdb und verein.fdb) als auch jeweils ein Bild davon hier mal rein, weil ich sicherstellen möchte, dass die unregelmäßigen Darstellungen von Zahlen (Felder plz und telefon) nachvollziehbar erhalten bleibt.

Auch mit SET WIDTH bekomme ich keine bündige Darstellung (bspw. der Postleitzahlen - Feld plz) geliefert.
Ich erwarte bei allen Datensätzen diese bündige Darstellung:
plz
-----
12345
12345
12345
usw.

Ich vermute, dass könnte mit den Umlauten zu tun haben, die in anderen Tabellenfeldern hin und wieder auftreten, denn nur dann kommt es offenbar zu diesen sehr unschönen 'Verwerfungen'.

Vielleicht könnte mal jemand prüfen:
a) passiert das auch bei Firebird 3.x
b) passiert das auch unter Windows
c) passiert das auch bei Verwendung einer anderen Linux-Distri
d) passiert das auch unter Linux Mint bei Verwendung eines anderen Terminals

Danke fürs Checken.

Viele Grüße
Gerd

Sitzung adressen.fdb

Code: Alles auswählen

gerd@gerd-MS-7641:~$ isql adressen.fdb
Database: adressen.fdb, User: GERD
SQL> SELECT name, plz FROM anschrift;

NAME                                                                                                 PLZ    
=============================================================================== ====== 
Bäuerchen                                                                                           66611  
Mustermann                                                                                           12345  
Mustermann                                                                                           12345  
Wolf                                                                                                 55555  
Blumenstengel                                                                                        12345  
Blumenstengel                                                                                        12345  
Illing                                                                                               12345  
Bräutigam                                                                                           77777  
Meier                                                                                                88888  
Berg                                                                                                 66666  
Dürkopp                                                                                             11111  
Feilchen                                                                                             12312  
Moor                                                                                                 14149  
Bärlein                                                                                             98653  
Bärlein                                                                                             98653  
Musterfrau                                                                                           98653  
Rieß                                                                                                90012  
Rieß                                                                                                90012  
Paggy                                                                                                11111  

SQL> SELECT vorname, plz FROM anschrift WHERE vorname LIKE '%H%';

VORNAME                                            PLZ    
================================================== ====== 
Heidi                                              12345  
Heidi                                              12345  
Hans-Jürgen                                       12345  
Hannelore                                          66666  
Hennry                                             12312  
Hannelore                                          14149  
Hannelore                                          90012  

SQL>

Sitzung verein.fdb

Code: Alles auswählen

gerd@gerd-MS-7641:~$ isql verein.fdb
Database: verein.fdb, User: GERD
SQL> SHOW VIEWS;
V_TELEFONLISTE

SQL> SELECT * FROM v_telefonliste;

          ID VORNAME                                            NAME                                               TELEFON         
============ ================================================== ================================================== =============== 
           1 Hans                                               Glücklich                                         1234555555      
           1 Hans                                               Glücklich                                         1234666666      
           2 Bertram                                            Traurig                                            5678444444      
           3 Ilse                                               Depri                                              9876333333      

SQL> SELECT id, telefon FROM v_telefonliste;

          ID TELEFON         
============ =============== 
           1 1234555555      
           1 1234666666      
           2 5678444444      
           3 9876333333      

SQL> SELECT vorname, telefon FROM v_telefonliste;

VORNAME                                            TELEFON         
================================================== =============== 
Hans                                               1234555555      
Hans                                               1234666666      
Bertram                                            5678444444      
Ilse                                               9876333333      

SQL> SELECT name, telefon FROM v_telefonliste;

NAME                                               TELEFON         
================================================== =============== 
Glücklich                                         1234555555      
Glücklich                                         1234666666      
Traurig                                            5678444444      
Depri                                              9876333333      

SQL> SHOW TABLE mitglieder;
ID                              INTEGER Not Null 
VORNAME                         VARCHAR(50) Nullable 
NAME                            VARCHAR(50) Not Null 
CONSTRAINT INTEG_3:
  Primary key (ID)
SQL> SHOW TABLE kommunikation;
ID                              INTEGER Not Null 
MITGLIED_NR                     INTEGER Not Null 
TELEFON                         VARCHAR(15) Nullable 
CONSTRAINT FK_KOMM:
  Foreign key (MITGLIED_NR)    References MITGLIEDER (ID) On Update Cascade On Delete Cascade
CONSTRAINT INTEG_6:
  Primary key (ID)
SQL> SHOW VIEW v_telefonliste;
ID                              INTEGER Not Null 
VORNAME                         VARCHAR(50) Nullable 
NAME                            VARCHAR(50) Not Null 
TELEFON                         VARCHAR(15) Nullable 
View Source:
==== ======
SELECT
mitglieder.id ,
mitglieder.vorname,
mitglieder.name,
kommunikation.telefon
FROM mitglieder
JOIN kommunikation
ON mitglieder.id = kommunikation.mitglied_nr
SQL>

Bilder

Zu b) passiert das auch unter Windows

Habe ich gerade mal mit Windows 7 Professional 64-bit geprüft.

Dort ist die Anzeige erwartungsgemäß. OK

: Sitzung verein_fdb - unter Windows 7 Prof 64-bit.png (4.87 KiB) 24016 mal betrachtet

Habe das zum Anlass genommen und mir den Snapshot Build vom 2020-04-20, 01:51:23 installiert:
ISQL Version: LI-T4.0.0.1902 Firebird 4.0 Beta 1

Auch damit ist die Darstellung - wie ich meine - nicht in Ordnung.

(Ich arbeite jetzt mit dieser Version weiter. Bei der Installation gab es keine Probleme. Meine Firebird Datenbanken können alle bearbeitet werden. Zeitlicher Aufwand: ca. 10 Minuten. Sehr schön.)

Viele Grüße
Gerd

Hi Gerd,

bitte zeige uns mal die DDL zu deinen Tabellen. Sind die Telefonnummer auch als Zahlen deklariert? Im ersten Ansatz sehe ich die Probleme ebenfalls im Zusammenhang mit den Umlauten.

Gruß
Martin

Ich nehme mal an, eine DB/Tabelle ist in UTF8, die 2. Tabelle ist in ISO8859-1 bzw. WIN1252 kodiert.
Bei der Ausgabe wird nun für die Formatierung eine Anzahl Leerzeichen hinzugefügt, die von der Byte-Länge ausgeht.
Bei der Darstellung verschiebt sich das Bild dann leider, da hier die Zeichenlänge verwendet wird und aus den 2-Byte UTF8 für Umlaute nur 1 Zeichen dargestellt wird.

Bei grafischen Tools, die Daten-Grids verwenden wird dies nicht passieren.
Bei dem simplen ISQL gehts halt so nicht. Aber das ist ja auch nur ein Werkzeug und nicht für den Endanwender.

Wenn du allerdings in der Connection CHARSET=WIN1252 o.ä. verwendest, wandelt die DB von UTF8 in WIN1252 für den Client um, so dass ISQL damit zurechtkommen müsste.
Allerdings muss dann die "DOS"-Box nicht mehr in CP 65001 fahren.

Hallo Martin.

martin.koeditz hat geschrieben: Mo 20. Apr 2020, 21:07 Hi Gerd,

bitte zeige uns mal die DDL zu deinen Tabellen. Sind die Telefonnummer auch als Zahlen deklariert? ...

Siehe bitte Code-Abschnitt: "Sitzung verein.fdb"
Nein die Telefonnummer und übrigens auch die plz (für: Postleitzahl) sind als Datentyp VARCHAR() festgelegt. (--> Beides sind Test-Datenbanken - erstellt mit der v4.0 Beta 1.)

DDL:

KOMMUNIKATION

Code: Alles auswählen

CREATE TABLE KOMMUNIKATION (
	ID INTEGER NOT NULL,
	MITGLIED_NR INTEGER NOT NULL,
	TELEFON VARCHAR(15),
	PRIMARY KEY (ID)
);

ALTER TABLE KOMMUNIKATION
	ADD FOREIGN KEY (MITGLIED_NR) 
	REFERENCES MITGLIEDER (ID);


CREATE INDEX FK_KOMM ON KOMMUNIKATION (MITGLIED_NR);

MITGLIEDER

Code: Alles auswählen

CREATE TABLE MITGLIEDER (
	ID INTEGER NOT NULL,
	VORNAME VARCHAR(50),
	NAME VARCHAR(50) NOT NULL,
	PRIMARY KEY (ID)
);

Und auch bei einer VIEW (hier auf die Datenbank verein.fdb) - natürlich ausgeführt mit dem ISQL Tool - würde es diese 'unbündige' Darstellung geben:

Code: Alles auswählen

CREATE VIEW V_TELEFONLISTE (ID,VORNAME,NAME,TELEFON) AS SELECT
mitglieder.id ,
mitglieder.vorname,
mitglieder.name,
kommunikation.telefon
FROM mitglieder
JOIN kommunikation
ON mitglieder.id = kommunikation.mitglied_nr;

Viele Grüße
Gerd

Hallo bfuerchau.

bfuerchau hat geschrieben: Di 21. Apr 2020, 09:53 Ich nehme mal an, eine DB/Tabelle ist in UTF8, die 2. Tabelle ist in ISO8859-1 bzw. WIN1252 kodiert. ...

Das wäre eine nachvollziehbare Möglichkeit. Nur, ich habe hier bspw. bei der Datenbank verein.fdb den Standard belassen bei:
:: Linux Mint
:: GNOME Terminal
:: ISQL Tool --> CREATE DATABASE (minimalistisch)
:: ISQL Tool --> CREATE TABLE
:: ISQL Tool --> ALTER TABLE
:: ISQL Tool --> INSERT
:: ISQL Tool --> SELECT

An welcher dieser Stellen bitte, müsste ich denn wie vom Standard (UTF8) 'abgedriftet' sein?

bfuerchau hat geschrieben: Di 21. Apr 2020, 09:53 ... Bei grafischen Tools, die Daten-Grids verwenden wird dies nicht passieren.

Das stimmt. Kann ich hier nachvollziehen.

bfuerchau hat geschrieben: Di 21. Apr 2020, 09:53 ... Bei dem simplen ISQL gehts halt so nicht. Aber das ist ja auch nur ein Werkzeug und nicht für den Endanwender. ...

Das sehe ich nicht so, auch mit Blick auf das eine oder andere DB-System.

Viele Grüße
Gerd

Hallo in die Runde.

bfuerchau hat geschrieben: Di 21. Apr 2020, 09:53 ... Wenn du allerdings in der Connection CHARSET=WIN1252 o.ä. verwendest, wandelt die DB von UTF8 in WIN1252 für den Client um, so dass ISQL damit zurechtkommen müsste.
Allerdings muss dann die "DOS"-Box nicht mehr in CP 65001 fahren.

@bfuerchau: So, ich denke, dass ich da etwas gefunden habe, was das Verhalten erklärt und auch beseitigt.

Ich habe mit dem ISQL-Tool zwei Firebird Datenbanken erzeugt:

:: Testnone.fdb
:: Testutf.fdb

NONE ist, so habe ich das gelesen, die Standard-Einstellung beim Erzeugen einer Firebird Datenbank.
Die Übernahme von NONE beim CREATE DATABASE scheint wohl der Grund dafür zu sein, dass es zu dieser 'unbündigen' Anzeige kommt:

:: Testnone.fdb

Code: Alles auswählen

gerd@gerd-MS-7641:~$ isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> CREATE DATABASE '/home/gerd/Firebird/Datenbanken/Testnone.fdb'
CON> USER 'sysdba' PASSWORD 'geheimes_passwort';
SQL> CREATE TABLE adressen (
CON> name VARCHAR(20),
CON> plz VARCHAR(20)
CON> );
SQL> INSERT INTO adressen values ('Muller', '12345');
SQL> INSERT INTO adressen values ('Müller', '12345');
SQL> INSERT INTO adressen values ('Moller', '12345');
SQL> INSERT INTO adressen values ('Möller', '12345');
SQL> INSERT INTO adressen values ('Maller', '12345');
SQL> INSERT INTO adressen values ('Mäller', '12345');
SQL> SELECT * FROM adressen;

NAME                 PLZ                  
==================== ==================== 
Muller               12345                
Müller              12345                
Moller               12345                
Möller              12345                
Maller               12345                
Mäller              12345                

SQL>

Weise ich beim CREATE DATABASE NAMES und DEFAULT CHARACTER UTF8 zu, dann ist die Anzeige korrekt.

:: Testutf.fdb

Code: Alles auswählen

gerd@gerd-MS-7641:~$ isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> CREATE DATABASE '/home/gerd/Firebird/Datenbanken/Testutf.fdb'
CON> USER 'sysdba' PASSWORD 'geheimes_passwort'
CON> PAGE_SIZE 8192
CON> SET NAMES 'UTF8'
CON> DEFAULT CHARACTER SET UTF8;
SQL> CREATE TABLE adressen (
CON> name VARCHAR(20),
CON> plz VARCHAR(20)
CON> );
SQL> INSERT INTO adressen values ('Muller', '12345');
SQL> INSERT INTO adressen values ('Müller', '12345');
SQL> INSERT INTO adressen values ('Moller', '12345');
SQL> INSERT INTO adressen values ('Möller', '12345');
SQL> INSERT INTO adressen values ('Maller', '12345');
SQL> INSERT INTO adressen values ('Mäller', '12345');
SQL> SELECT * FROM adressen;

NAME                 PLZ                  
==================== ==================== 
Muller               12345                
Müller               12345                
Moller               12345                
Möller               12345                
Maller               12345                
Mäller               12345                

SQL>

Ich glaube hierüber bin ich schon einmal allerdings unter Windows gestolpert.
Da ging es um Darstellungsprobleme z. B. bei den dt. Umlauten mit dem ISQL Tool. Mit einen entsprechenden Verbindungsstring konnten dort die Probleme geklärt werden.

Dachte echt, dass Linux und Firebird unter Linux alles erst einmal UTF8 ist. Scheint wohl nicht der Fall zu sein.

Na gut, damit (= CREATE DATABASE mit vorzunehmender UTF8-Zuweisung) kann ich gut leben.
Hoffentlich hat diese 'erweiterte Art' meines DATABASE CREATE nicht an anderer Stelle irgendwelche Auswirkungen - aber das bekomme ich dann schon noch mit.
Danke!

Viele Grüße
Gerd

Man muss halt immer den Unterschied zwischen DB und Anwendung betrachten.
Das kann immer wieder zu Problemen führen, wenn die Codepages nicht harmonieren.

In den meisten Anwendungen sind Strings inzwischen UCS2 (bzw. Widechar), im allgemeinen Sprachgebrauch "Unicode".
Dem ist nun mal leider nicht so.
Strings/Widechar sind nicht vollständig Unicode, das wäre UCS4 sondern eben UCS2, was ein fixer 2-Byte-Code ist und 65535 Zeichen umfasst.
Demgegenüber steht UTF8, was ein variabler Zeichensatz von 1-4 Bytes und UTF16, was ein variabler Zeichensatz von 2/4-Bytes ist.
In moderneren DB's gibt es ja nun den Typ "N[var]CHAR", der i.d.R. als UTF16 festgelegt wird.

Wenn ich eine DB mit CHARSET NONE bediene, erfgolgt zwischen Treiber und DB keine Umwandlung, es wird alles Binär betrachtet.
Verwendet die Anwendung nun einen String, wird dieser i.d.R. in die Codepage des Prozesses umgewandelt, Windows z.B. 1252 oder beim Lesen eben von Codepage in String.
Dabei kann es dann bei der Verwendung von Sonderzeichen bereits zu Problemen kommen.
Am Besten ist natürlich grundsätzlich:
- Der DB eine Codepage zu verpassen
- In der Anwendung eine Codepage passend zur Anwendung wäheln
Arbeite ich dann mit Strings habe ich die geringsten Probleme.

Bei der Verwendung von UTF8 in der FB ist noch zu beachten:
Die maximale Indexlänge reduziert sich auf 1/4 je Block.
D.h.: bei einer Segmentgröße von 8KB ist bei WIN1252 der Index max. 2KB (1 Byte = 1 Zeichen), bei UTF8 dann nur 512 Zeichen (4Bytes = 1 Zeichen).
Bei der Recordlänge ist es wieder unerheblich, da ja grundsätzlich komprimiert wird.
Bei bestimmten Stringfunktionen kommt es zu Microverlangsamungen, da der String für den DB-Server, der ja auch eine Anwendung ist, erst von UTF8 in UCS2 umgewandelt werden muss um z.B. POSITION oder SUBSTRING korrekt berechnen zu können, denn hier werden die Zeichen und nicht die Bytes benötigt.

Hallo. bfuerchau.

bfuerchau hat geschrieben: Mi 22. Apr 2020, 09:55 Man muss halt immer den Unterschied zwischen DB und Anwendung betrachten. Das kann immer wieder zu Problemen führen, wenn die Codepages nicht harmonieren.
...
- Der DB eine Codepage zu verpassen
- In der Anwendung eine Codepage passend zur Anwendung wäheln
Arbeite ich dann mit Strings habe ich die geringsten Probleme.
...

Werde mir eine Datei (CREATE DATABASE) anlegen und die mittels ISQL Tool (-input) einlesen und durchführen lassen.

Habe mir auch gleich einmal Lazarus geschnappt und passend zu diesem Thema dort diese Einstellungen durchgeführt:

: Lazarus CharSet im IBConnection-String.png (156.09 KiB) 23971 mal betrachtet

Möchte mal interessehalber wissen, ob sich das mit php bei dieser Vorgehensweise (CharSet-Angaben: UTF8, ISO8859_1, NONE, LEER) auch so darstellen würde.

@bfuerchau: Deine Erklärungen zum Thema finde ich wieder einmal hilfreich. Dafür danke ich Dir!

Viele Grüße
Gerd

Firebirdforum.de

ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung

Re: ISQL Version: LI-T4.0.0.1436 - Unschöne, da unbündige Darstellung