Hallo zusammen,
ich habe eine neue Datenbank angelegt und bin nun dabei die Tabellen zu erstellen.
Bei einer Tabelle bekomme ich folgende Fehler-Meldung
Error Message:
----------------------------------------
This operation is not defined for system tables.
unsuccessful metadata update.
new record size of 65878 bytes is too big.
TABLE TEXTE.
------------------------------------------------
SQLCODE: -607
SQLSTATE: 54000
GDSCODE: 335544351
Die gleiche Tabelle habe ich unter FB 2.5 vor einigen Jahren problemlos anlegen können.
Ich habe die Datenbank über IbExpert angelegt und als Seitengröße 16384
angegeben, weil er mir bei der Auswahl 32768 eine Fehler-Meldung "wrong numeric type / short integer expected" brachte.
Was mache ich falsch ?
Danke und Gruss
Hamburgo
Anlegen einer Tabelle unter FB 3.0: new record size of 65878 bytes is too big.
Moderator: thorben.braun
Wenn du mehr als 32KB Satzlänge benötigst must du bei den großen Feldern auf CLOB/BLOB umsteigen. Die 32KB Grenze gilt halt immer noch.
Ansonsten musst du die Tabelle in mehrere kleine Tabellen mit passenden Beziehungen erstellen.
Ansonsten musst du die Tabelle in mehrere kleine Tabellen mit passenden Beziehungen erstellen.
Ist das Grenze mit 32 KB Satzlänge in FB 3.0 neu ?
Weil, wie gesagt, ich dieselbe Tabelle exakt so unter FB 2.5 anlegen und problemlos damit
arbeiten konnte.
Oder liegt es evtl. am Wechsel des CharSets von ISO-8859-1 auf UTF8, das dadurch die Sätze länger werden und deshalb die 32 KB überschreiten ?
Gruss
Hamburgo
Weil, wie gesagt, ich dieselbe Tabelle exakt so unter FB 2.5 anlegen und problemlos damit
arbeiten konnte.
Oder liegt es evtl. am Wechsel des CharSets von ISO-8859-1 auf UTF8, das dadurch die Sätze länger werden und deshalb die 32 KB überschreiten ?
Gruss
Hamburgo
Stimmt.
Bei UTF8 gibst du ja die Anzahl Zeichen und nicht die Anzahl Bytes an.
UTF8 benötigt den 4fachen Platz, da UTF8 eine variable Speicherung zwischen 1 und 4 Bytes (= 1 Zeichen) belegt. Die FB rechnet da dann immer mit dem Maximum.
Dies kann dann u.U. auch dei maximale Schlüssellänge bei Compound Keys überschreiten.
Du musst dir vom Design her überlegen, welche Felder tatsächlich in UTF8 sein müssen (Namen,. Orte, Bezeichnungen).
Schlüsselfelder wir Produkt, Gruppe, Konto usw. müssen nicht in UTF8 gespeichert werden.
Wenn die DB auf UTF8 gestellt ist, werden alle CHAR(N) automatisch UTF8. Du solltest hier dann beim "FELD CHAR(N) CHARSET ISO8859-1" verwenden, oder den Default der DB auf ISO8859-1/WIN1252 belassen und explizit nur benötigte Felder mit "FELD CHAR(N) CHARSET UTF8" erstellen.
Bei UTF8 gibst du ja die Anzahl Zeichen und nicht die Anzahl Bytes an.
UTF8 benötigt den 4fachen Platz, da UTF8 eine variable Speicherung zwischen 1 und 4 Bytes (= 1 Zeichen) belegt. Die FB rechnet da dann immer mit dem Maximum.
Dies kann dann u.U. auch dei maximale Schlüssellänge bei Compound Keys überschreiten.
Du musst dir vom Design her überlegen, welche Felder tatsächlich in UTF8 sein müssen (Namen,. Orte, Bezeichnungen).
Schlüsselfelder wir Produkt, Gruppe, Konto usw. müssen nicht in UTF8 gespeichert werden.
Wenn die DB auf UTF8 gestellt ist, werden alle CHAR(N) automatisch UTF8. Du solltest hier dann beim "FELD CHAR(N) CHARSET ISO8859-1" verwenden, oder den Default der DB auf ISO8859-1/WIN1252 belassen und explizit nur benötigte Felder mit "FELD CHAR(N) CHARSET UTF8" erstellen.
Danke, dann haben wir ja den Grund gefunden.
Leider muss ich genau diese Tabelle rein in UTF8 halten, da sie die Texte von Arbeitsnachweisen speichert.
Zunächst werde ich mal testen, wie lang die Texte unter UTF8 sein können und sollte das zu knapp sein für die Texte der Arbeitsscheine, dann lege ich halt mehrere Unter-Tabellen an und speicher dort den überschüssigen Text, der in die Haupt-Tabelle nicht reinpasst.
Das ist für mich einfacher. Ich halte nichts davon, aus Platz-Gründen mit unterschiedlichen Zeichsätzen zu operieren und dann ggf. bei der Ausgabe auf Papier oder Monitor nicht zu vergessen konvertieren zu müssen.
Gruss
Hamburgo
Leider muss ich genau diese Tabelle rein in UTF8 halten, da sie die Texte von Arbeitsnachweisen speichert.
Zunächst werde ich mal testen, wie lang die Texte unter UTF8 sein können und sollte das zu knapp sein für die Texte der Arbeitsscheine, dann lege ich halt mehrere Unter-Tabellen an und speicher dort den überschüssigen Text, der in die Haupt-Tabelle nicht reinpasst.
Das ist für mich einfacher. Ich halte nichts davon, aus Platz-Gründen mit unterschiedlichen Zeichsätzen zu operieren und dann ggf. bei der Ausgabe auf Papier oder Monitor nicht zu vergessen konvertieren zu müssen.
Gruss
Hamburgo
Konvertieren brauchst du gar nichts, das macht der DB-Treiber für dich.
Allerdings auch nur, wenn du in der Verbindungsfolge deinen CHARSET=UTF8 auch angibst.
Strings sind in allen Programmiersprachen (außer C++, da gibt's BSTR), immer Unicode. Beim Lesen wird vom CHARSET in Unicode umgewandelt, beim Schreiben von Unicode in den CHARSET. Bei letzterem gehen dann ungültige Zeichen verloren, wenn das CHARSET die Zeichen nicht enthält. Das Ersatzzeichen dabei ist dann das "?".
Beim Drucken gibts genauso wenig Probleme, man muss nur eine Unicode-Schrift verwenden. Dies kann man mit dem Programm "Zeichentabelle => erweiterte Ansicht" aber feststellen, welche Sprachbereiche in der Schrift abgedeckt werden.
Wenn du nur Texte speicherst, die naturgegeben nicht als Index benötigt werden, speichere die Daten als "blob sub_type text character set utf8". Da gehen dann je Feld bis 4GB an Daten rein, macht 1GB in UTF8.
Ich speichere da gerne meine vielen XML-Dokumente ganz locker ab.
Allerdings auch nur, wenn du in der Verbindungsfolge deinen CHARSET=UTF8 auch angibst.
Strings sind in allen Programmiersprachen (außer C++, da gibt's BSTR), immer Unicode. Beim Lesen wird vom CHARSET in Unicode umgewandelt, beim Schreiben von Unicode in den CHARSET. Bei letzterem gehen dann ungültige Zeichen verloren, wenn das CHARSET die Zeichen nicht enthält. Das Ersatzzeichen dabei ist dann das "?".
Beim Drucken gibts genauso wenig Probleme, man muss nur eine Unicode-Schrift verwenden. Dies kann man mit dem Programm "Zeichentabelle => erweiterte Ansicht" aber feststellen, welche Sprachbereiche in der Schrift abgedeckt werden.
Wenn du nur Texte speicherst, die naturgegeben nicht als Index benötigt werden, speichere die Daten als "blob sub_type text character set utf8". Da gehen dann je Feld bis 4GB an Daten rein, macht 1GB in UTF8.
Ich speichere da gerne meine vielen XML-Dokumente ganz locker ab.