Seite 1 von 1

VARCHAR-Feldlänge in Firebird 4-mal so lang, wie definiert

Verfasst: Do 14. Mär 2019, 12:02
von gg51
Ich teste gerade LO Version 6.2.0.3 (x64) unter Windows 10 Pro (x64). Bei Verwendung von HSQLDB verhält sich die Datenbank wie erwartet. Ein Textfeld vom Typ VARCHAR kann nur so lang sein, wie definiert. Beim Versuch, einen längeren Text einzugeben, kommt eine Fehlermeldung. Das Speichern ist nur möglich, wenn der Text zur Definition passt. Bei Verwendung von Firebird tritt das Phänomen auf, dass die Feldlänge intern 4-mal so lang gespeichert wird, wie eigentlich definiert - obwohl in der Entwurfsansicht der richtige Wert angezeit wird. Beim Versuch, einen längeren Text einzugeben, kommt keine Fehlermeldung. Gespeichert werden aber maximal nur soviele Zeichen, wie sich aus der Definition von Feldlänge x 4 ergeben. Ist das ein Bug in LO Base oder Firebird oder muß da noch irgendwo etwas von mir konfiguriert werden?

Re: VARCHAR-Feldlänge in Firebird 4-mal so lang, wie definiert

Verfasst: Do 14. Mär 2019, 17:28
von RobertG
Hallo gg51,

Firebird ist zwar inzwischen einige Zeit in LO dabei, für bestimmte Anwendungen weiterhin aber nicht als interne Datenbank nutzbar. Dazu gehört auch das Problem der Zeichenlänge. Das fängt mit diesem Bug an:
https://bugs.documentfoundation.org/sho ... ?id=105711
Da kannst Du einmal ganz nach unten Scrollen und die Verwirrung mit bekommen. Firebird scheint 4 Bytes in der UTF-8-Variante für jeden Buchstaben zu reservieren. Die ersten 128 Buchstaben (also nicht die Sonderzeichen ä, ö, ü ...) brauchen aber nur 1 Byte. also lässt die Datenbank zu, dass da insgesamt 4 Buchstaben dieser Art statt eines Buchstabens möglich sind.

Ich würde gerne Firebird in einigen Bereichen wegen der zusätzlichen Funktionen nutzen. Zur Zeit ist mir die Integration aber noch nicht ausgereift genug.

Gruß

Robert

Re: VARCHAR-Feldlänge in Firebird 4-mal so lang, wie definiert

Verfasst: Fr 15. Mär 2019, 07:57
von Wanderer
Hallo,

die Platzfrage würde ich erstmal nicht als Bug sehen. Da ich nicht weiß, ob der Anwender irgendwann 100 chinesische 4-Byte Zeichen speichern will, muss ich 4 Mal mehr Bytes als Zeichen reservieren, um keine Inhaltsvorgaben zu machen, die niemand brauchen kann.

Die Datenbank selbst muss also einen 200 Byte ASCII String nicht abschneiden, da ein 100 Zeichen/400 Byte Feld nur halb voll ist.
Frage ist, sollte sie das beim Speichern trotzdem tun?
Wenn Sie dafür bei jedem String analysieren muss, aus welchen Zeichen er besteht, würde Speichern wohl um einiges länger dauern.

Es wäre zwar wünschenswert, wenn man das Verhalten einstellen könnte, aber wir müssen uns auch als Programmierer auf die Eigenschaften von UTF8 einstellen.
Also müssen wir eventuell Strings in Zukunft bei der Eingabe beschneiden, wie man ja auch andere Daten auf Plausibilität oder Gültigkeit prüfen kann.

MfG, Jörn

Re: VARCHAR-Feldlänge in Firebird 4-mal so lang, wie definiert

Verfasst: Fr 15. Mär 2019, 17:16
von RobertG
Hallo Jörn,

wenn ich eine Zeichenlänge für ein Tabellenfeld einstelle, und das tue ich mit VARCHAR(20), dann hat sich die Datenbank daran zu halten. Eine Eingabe nur über ein Formular zu begrenzen hieße der direkten Eingabe in Tabellen eben die Beschränkung nicht zu geben und dort dann andere Inhalte speichern und auslesen zu können als aus dem Formular. In das Feld VARCHAR(20) kann ich zur Zeit 80 Zeichen aus dem Bereich ohne deutsche Sonderzeichen eingeben. Gebe ich nur deutsche Sonderzeichen ein, so werden daraus 40 Zeichen. Mit der Längenangabe kann ich also nichts anfangen.

Alle mir sonst bekannten Datenbanken bekommen so etwas geregelt. Wenn Firebird das nicht gebacken bekommt, dann taugt es für den Einsatz zusammen mit einer GUI von Base eben nicht. Das ist schon merkwürdig, wie unterschiedlich Firebird mit den Längenbegriffen von Strings umgeht. Mit der Funktion CHAR_LENGTH() ist die interne Firebird-DB nämlich inzwischen sehr wohl in der Lage, die genaue Zeichenlänge eine Strings unabhängig von der Zeichenart auszugeben. Bei BIT_LENGTH() zeigt dann die interne Firebird-DB an, dass es alle Sonderzeichen auf 16bit umsetzt, die anderen Zeichen auf 8bit. HSQLDB macht hier aus allen Zeichen 16bit. Wenn sich Firebird einfach an ihre eigne CHAR_LENGTH() halten würde, dann gäbe es zumindest das Problem mit der falschen Deutung einer Stringlänge nicht mehr.

Gruß

Robert

Re: VARCHAR-Feldlänge in Firebird 4-mal so lang, wie definiert

Verfasst: Fr 22. Mär 2019, 09:20
von Wanderer
Hallo,
RobertG hat geschrieben:
Fr 15. Mär 2019, 17:16
Bei BIT_LENGTH() zeigt dann die interne Firebird-DB an, dass es alle Sonderzeichen auf 16bit umsetzt, die anderen Zeichen auf 8bit. HSQLDB macht hier aus allen Zeichen 16bit.
dann nehme ich mal an, daß Du im wesentlichen mit deutschen Umlauten getestet hast. Falls Du ein paar chinesische Namen
in Deiner Datenbank hast sollten schon 3 Bytes nötig sein. Wofür die 4-Byte-Zeicheen genutzt werden müsste ich erst nachsehen.

Ich bin von SQLITE her den etwas weniger strengen Ansatz durchaus gewohnt https://www.sqlite.org/datatype3.html
und hätte auch nichts dagegen wenn die Daten direkt beim INSERT nach CHAR_LENGTH abgeschnitten werden.
Was wir nicht ändern können ist der 4-fache Platzbedarf, wenn wir keine Inhaltsvorgaben machen wollen.
Alternative wäre nur ein externer String-Pool mit variablen Längen - aber über die Interna soll man ja bei Datenbanken nur wenig nachdenken müssen.

mfg, Jörn