Steht in obigem Link:
https://firebirdsql.org/file/documentat ... ts-de.html
Transaction Counter zurücksetzen
Moderator: thorben.braun
Hallo.
Habe die Fehlermeldung am Beispiel einer DB-Tabelle ANSCHRIFT erzwungen. Sie kann nun hier gefunden werde.
Die ausgegebenen Fehlermeldungen:
Statement failed, SQLSTATE = 54000
unsuccessful metadata update
-TABLE ANSCHRIFT
-too many versions
Die Anweisung ist fehlgeschlagen.
Kein erfolgreiches Metadaten-Update.
- Tabelle ANSCHRIFT (255 Mal relevant geändert. An ihr können keine Änderungen mehr vorgenommen werden.)
- Zu viele Versionen.
Viele Grüße
Gerd
Habe die Fehlermeldung am Beispiel einer DB-Tabelle ANSCHRIFT erzwungen. Sie kann nun hier gefunden werde.
Code: Alles auswählen
gerd@gerd-MS-7641:~$ isql adressen.fdb
Database: adressen.fdb, User: GERD
SQL> ALTER TABLE ANSCHRIFT ALTER COLUMN PLZ TYPE VARCHAR(5);
...
...
...
SQL> ALTER TABLE ANSCHRIFT ALTER COLUMN PLZ TYPE VARCHAR(255);
Statement failed, SQLSTATE = 54000
unsuccessful metadata update
-TABLE ANSCHRIFT
-too many versions
SQL>
Statement failed, SQLSTATE = 54000
unsuccessful metadata update
-TABLE ANSCHRIFT
-too many versions
Die Anweisung ist fehlgeschlagen.
Kein erfolgreiches Metadaten-Update.
- Tabelle ANSCHRIFT (255 Mal relevant geändert. An ihr können keine Änderungen mehr vorgenommen werden.)
- Zu viele Versionen.
Viele Grüße
Gerd
Linux Mint 21.3 Virginia Cinnamon 6.0.4
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Um den Spaltentyp anzupassen bedarf es keiner Änderung der Tabelle sondern der Änderung der Domain.
Da die Daten ja komprimiert abgelegt werden, ist eine Verlängerung unkritisch. Eine Typänderung ist natürlich nicht möglich.
https://firebirdsql.org/file/documentat ... mn-de.html
Auch wenn du nicht mit eigenen Domains arbeitest, macht das die Firebird automatisch.
Da ich sehr viel mit temporären Tabellen umgehe habe ich mir für alle möglichen Typen eigene Domains angelegt. Das Erstellen von Tabellen ist damit auch schneller, da man nur den Typ angeben muss und Ausprägung, Null, Default sind automatisch definiert.
Da die Daten ja komprimiert abgelegt werden, ist eine Verlängerung unkritisch. Eine Typänderung ist natürlich nicht möglich.
https://firebirdsql.org/file/documentat ... mn-de.html
Auch wenn du nicht mit eigenen Domains arbeitest, macht das die Firebird automatisch.
Da ich sehr viel mit temporären Tabellen umgehe habe ich mir für alle möglichen Typen eigene Domains angelegt. Das Erstellen von Tabellen ist damit auch schneller, da man nur den Typ angeben muss und Ausprägung, Null, Default sind automatisch definiert.
Hallo bfuerchau.
Das werde ich mal mit der 4.0 Beta 1 machen - hört sich sehr interessant an. Danke für den Hinweis.
Ich habe mir gedacht, dass es besser ist, für den Umgang mit DOMAINS ein neues Thema anzulegen. Es ist hier zu finden: viewtopic.php?f=4&t=111
Viele Grüße
Gerd
Das tat ich, um an die Fehlermeldung zu kommen, um sie hier einzustellen.
Temporäre Tabellen ...bfuerchau hat geschrieben: ↑Fr 3. Apr 2020, 09:49 ...
https://firebirdsql.org/file/documentat ... mn-de.html
Auch wenn du nicht mit eigenen Domains arbeitest, macht das die Firebird automatisch.
Da ich sehr viel mit temporären Tabellen umgehe habe ich mir für alle möglichen Typen eigene Domains angelegt. Das Erstellen von Tabellen ist damit auch schnelleer, ...
Das werde ich mal mit der 4.0 Beta 1 machen - hört sich sehr interessant an. Danke für den Hinweis.
Ich habe mir gedacht, dass es besser ist, für den Umgang mit DOMAINS ein neues Thema anzulegen. Es ist hier zu finden: viewtopic.php?f=4&t=111
Viele Grüße
Gerd
Linux Mint 21.3 Virginia Cinnamon 6.0.4
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Ich habe da meine eigenen "temporären Tabellen" entwickelt, da die "GLOBAL TEMPORARY TABLE"s (GTT) an die aktuelle Sitzung gebunden sind.
Daher erstelle ich mir eigene Tabellen TMPxxxxyy, wobei xxxx die SessionId ist und yy eine laufende Nummer.
Ursache:
Statt einen dicken SQL mit Join, Derived Tables, CTE's, Group By, ... zu machen zerlege ich die Aufgabe in Einzelschritte und führe das Ergebnis hinterher zusammen.
Dafür werden von mir bis zu 8 parallele Verbindungen aufgebaut (Classicseerver!), was mit GTT's nicht funktioniert.
Dabei gibt es ein kleines Problem, da 2 parallele CREATE TABLE's zu einem Inconsistency-Problem führen muss man dies über einen Globalen Lock über alle Sitzungen blocken.
Dies betrifft dann ebenso auch den Drop Table, wenn das Ergebnis vorliegt.
Insgesamt konnte ich meine Abfragen bis zum Faktor 1000! beschleunigen.
Für einfache Aufgaben ins besonders im Zusammenhang mit Prozeduren sind aber GTT's durchaus brauchbar
.
Daher erstelle ich mir eigene Tabellen TMPxxxxyy, wobei xxxx die SessionId ist und yy eine laufende Nummer.
Ursache:
Statt einen dicken SQL mit Join, Derived Tables, CTE's, Group By, ... zu machen zerlege ich die Aufgabe in Einzelschritte und führe das Ergebnis hinterher zusammen.
Dafür werden von mir bis zu 8 parallele Verbindungen aufgebaut (Classicseerver!), was mit GTT's nicht funktioniert.
Dabei gibt es ein kleines Problem, da 2 parallele CREATE TABLE's zu einem Inconsistency-Problem führen muss man dies über einen Globalen Lock über alle Sitzungen blocken.
Dies betrifft dann ebenso auch den Drop Table, wenn das Ergebnis vorliegt.
Insgesamt konnte ich meine Abfragen bis zum Faktor 1000! beschleunigen.
Für einfache Aufgaben ins besonders im Zusammenhang mit Prozeduren sind aber GTT's durchaus brauchbar
![Zwinkern ;)](./images/smilies/icon_e_wink.gif)