FB 1.5 distinct bei varchar(2048) DB geht hops

[Kostas]

Hallo Holger,

ich habe mit IBExpert ein Backup erzeugt mit der fbclient.dll aus der FB1.5 Server.
Danach ein Restore mit der fbclient.dll aus der FB3.0 Server.

Dabei bekomme ich die Fehlermeldung:
IBE: Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
Invalid metadata detected. Use -FIX_FSS_METADATA option.
Malformed string.
Exiting before completion due to errors.


FIX_FSS_METADATA habe ich nicht ausgeführt, sicherlich kann man das in IBExpert irgendwo eintragen.

Dann habe ich über IBExpert Extract Metadata nur die Struktur exportiert und wollte daraus eine neue FB3.0 DB anlegen. Die leere DB habe ich vorher angelegt. Bis auf ein paar Trigger wurde die DB angelegt. Danach Extract Metadata ohne Struktur jedoch mit Daten und importiert. Das hat funktioniert.

Die Systemtabellen habe ich nie angefasst.

Bezüglich des alten D5 Projektes, das kann ich eh nicht auf D11 umstellen. Der Aufwand ist viel zu groß. Noch zudem hatte ich einige Designfehler damals gemacht, auch das Unternehmen wurde in den über 20 Jahren in einigen Punkten geändert. Es macht nur Sinn die Anwendung komplett neu aufzusetzen. Der Kunde zieht nicht so recht weil die Anwendung stabil läuft. Aber es sind junge Nachfolger die den Betrieb übernehmen und wir sind schon in Kontakt. Mal sehen wie sich das entwickelt.

[Lemmy]

Zitat von IBExpert:

warum klappte backup/restore nicht?

sonst mach die db einfach mit fb25 auf (das geht auch mit fb15 datenbanken) und mach darüber backup/Restore.
ich kenn eigentlich keinen wirklichen grund, warum backup/restore nicht möglich sein sollte, es sei denn die db war schon
mit diversen updates auf systemtables ruiniert, das wüsste man aber.

ähm.. \misc\upgrade\metadata vergessen?

Zitat:

Dabei bekomme ich die Fehlermeldung:
IBE: Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
Invalid metadata detected. Use -FIX_FSS_METADATA option.
Malformed string.
Exiting before completion due to errors.

schau dir den Inhalt von Firebird\misc\upgrade\metadata und führ die genannten Schritte aus, dann sollte das passen. ggf. hat FB 3 noch weitere Anpassungen...

[IBExpert]

Zitat von Kostas:

FIX_FSS_METADATA habe ich nicht ausgeführt, sicherlich kann man das in IBExpert irgendwo eintragen.

ist eigentlich unten im restore dialog unübersehbar
https://www.ibexpert.net/ibe/pmwiki....estoreDatabase

wird auch nur ein mal gebraucht beim schritt von fb<=20 auf fb>=21

viel glück bei der Kommunikation mit den neuen Chefs, oft sind die übrigens
durchaus bereitwilliger zu verstehen, das uralte Version nun mal offene
Sicherheitslücken haben können, ob das relevant ist, kann eh niemand sagen,
aber wenn irgendwann mal jemand da doch in was seltsames reinläuft
oder daten verliert, hilft es immer weiter, derartige Vorschläge nicht
nur mündlich gemacht zu haben

[Delphi.Narium]

Zitat von Kostas:

Zitat von Delphi.Narium:

Wie greift Ihr denn auf FireBird zu?

Ich bin mir jetzt nicht sicher auf was du dich beziehst. Wenn es um den distinct Fehler mit FB 1.5 geht, ist der Zugriff egal. Ausprobiert habe ich es direkt in IBExpert. Wenn du das Thema ansprichst alten Delphi5 Projekt mit FB1.5 hoch ziehen auf D11 mit FB3.0, hier wird IBObjects verwendet. Die habe ich auch für D11 lizenziert und funktionieren von D11 aus auf FB1.5 bis FB 3.0 problemfrei. Wenn ich das Projekt umschreiben würde, würde IBO nicht mehr verwenden da die Entwicklung seit Jahren stehen geblieben ist und der Support vom Jason überhaupt nicht funktioniert.

Gruß Kostas

Ich meinte: Bei Delphi 5 bleiben und trotzdem FireBird 3 verwenden.

[Kostas]

Zitat von IBExpert:

Zitat von Kostas:

FIX_FSS_METADATA habe ich nicht ausgeführt, sicherlich kann man das in IBExpert irgendwo eintragen.

ist eigentlich unten im restore dialog unübersehbar
https://www.ibexpert.net/ibe/pmwiki....estoreDatabase

Den Dialog habe ich mir schon angeschaut aber den Begriff "FIX_FSS_METADATA" sehe ich nicht.
es gibt nur "Fix malformed UNICODE_FSS data" und "Fix malformed UNICODE_FSS metadata"
Für die neue FB 3.0 DB hatte ich übrigens ebenfalls den Zeichensatz ISO8859_1 verwendet.

Oder ist "FIX_FSS_METADATA" = "Fix malformed UNICODE_FSS metadata"

[Kostas]

[QUOTE=Delphi.Narium;1509397]

Zitat von Kostas:

Zitat von Delphi.Narium:

Wie greift Ihr denn auf FireBird zu?

Gruß Kostas

Ich meinte: Bei Delphi 5 bleiben und trotzdem FireBird 3 verwenden.

ah, ok. Ich habe zwar IBO für D11 lizenziert aber ich habe mich nicht getraut IBO auf D5 zu aktualisieren. Aber du hast vollkommen recht. Ein Versuch ist auf jeden Fall wert.

[IBExpert]

Zitat von Kostas:

Oder ist "FIX_FSS_METADATA" = "Fix malformed UNICODE_FSS metadata"

Die Ähnlichkeit sollte durchaus übrzeugend sein oder?
unsere Bezeichnung hat da noch 2 extra wörter drin, ist aber funktional exakt das selbe

Als Hintergrund info: fb<=20 hat char/varchar/blob subtype text felder in den Systemtabellen
mit charset NONE.

Wenn du da in einem trigger oder SP source oder einer Description zum Beispiel Umlaute
benutzt hast war das technisch kein Problem, aber zeigte bei Verbindungen mit anderem
charset auf den Systemtabellen unsinn an (malformed string usw).

Durch den Fix werden die in den Systemtabllen benutzten Zeichen äöüß € etc meistens sauber
erkannt und nach dem fix in fb>=21 als saubere UNICODE_FSS Zeichen gespeichert.
das Euro zeichen hätte dann zB 3 statt vorher 1 byte belegt. wenn man den
backup/Restore danach noch mal mit dem parameter macht, schaut der sich aber die
neuen 3 bytes einzeln an weil der ja meint, das es NONE wäre und macht daraus wieder
neue UNICODE_FSS Codes. klingt zwar erst mal nicht schlimm, aber ein Kunde hat dabei
seine ca 50MB große Datenbank, die schon fb2.5 war, bei jedem wöchentlichen backup/restore
lauf aufgeblasen, so das die nach einem halben jahr ohne annähernd so viele neue Daten
auf ca 2GB aufgeblasen, weil er das beim gbak restore in seiner batch immer als param drin
hatte (doofe idee).

ca 95% von dem ganzen Platz in der DB belegten dabei daher Systemtabellen, das meiste glaub ich
rdb$relation_fields, weil dort die descriptions intensiv benutzt wurden, dadurch aber völllig
explodiert sind und auch alles lahm gelegt haben.

Konnten wir durch sum(char_length( auf den feldern dann rausfinden, weil es ganz sicher blobs
der Systemtabellen waren. Und auf den haben wir dann die quatschigen inhalte, die eh keiner
lesen kann, pr update gelöscht, danach backup/restore ohne den parameter und es war wieder klein
und schnell.