|
Datenbank: FB • Version: 1.5 • Zugriff über: FIREDAC
FB 1.5 distinct bei varchar(2048) DB geht hops
Hallo Zusammen,
gerade habe ich ein gemeines Problem festgestellt. Ich habe ein Select distinct mit ein paar Felder. Eines davon ist als varchar(2048) angelegt. Wenn ich dieses Select ausführe wird die Connection geschlossen und im Firebird.log steht: fbserver.exe: terminated abnormally (4294967295) INET/inet_error: read errno = 10054 ich versuche mal die DB auf FB 3.0 hoch zu ziehen. Mal sehen ob dieses Problem auch bei FB 3.0 entsteht. [Edit] Ich habe die DB natürlich nicht in FB 3.0 über Backup-/Restore überführen können. Die Struktur konnte ich allerdings exportieren und eine neue FB 3.0 anlegen. Ein paar Trigger hat er nicht angelegt aber das ist für den Test egal. Die betroffene Tabelle hatte auch glücklicherweise keine FKs und konnte somit die Daten über ein Script exportieren-/Importieren. Das Problem taucht bei FB 3.0 NICHT auf, nur bei FB 1.5. Gruß Kostas |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
"Überlange" Text-Felder (VARCHAR) als Blob (TEXT) und fertig.
Wir hatten im PgDAC nur Probleme bei Überlangen VARCHAR, welche in der DB aber ohne Länge deklariert waren. (die DB hatte dort Größeres erlaubt, aber im Programm wurde nur Speicher für bis zu 32KB/16KChars vorgesehn, was in einem Pufferüberlauf endete, falls wirklich mal mehr Text drin stand .... oder waren es 64KB/32KChars, aber egal) |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Bis zu einer Länge von 32KB bestehr bei FireBird eigentlich kein Unterschied zwischen eine CLOB un Varchar
|
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Das Projekt hat schon ein paar Jahre auf dem Buckel. Angefangen mit BDE und Paradox 4.0 und umgestellt auf Firebird 1.0. In FB 1.0 gab es Probleme mit Memos. Deshalb wurden damals lange varchars verwendet. In FB 1.5 gab es keine Probleme mit Memos und dieses Problem mit distinct ist bis jetzt noch nicht aufgefallen. Erst vor kurzem habe ich in einer Query ein Jon auf eine Tabelle mit so einem Feld und schon hat es geknallt.
Das Projekt umstellen auf FB 3.0 geht nicht. Ich habe Fremdkomponenten im Einsatz die es nicht mehr gibt wie z.B. ToolBar2000/TBX . Deshalb muss ich auch Delphi 5 verwenden für dieses Projekt. |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Wenn es nur um dise Komponente geht, könnte ich dir eine für Unicode Delphi angepasste Version zukommen lassen. Sie entspricht allerdings nicht mehr zu 100% dem Original, da ich diese jeweils für meine Bedürfnisse angepasst/erweitert habe. Die Komponenten laufen bei mir aktuell mit D11 problemlos.
|
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Zitat:
Gruß Kostas |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Wie greift Ihr denn auf FireBird zu?
Im Zweifel kann man per ADO-Komponenten und ODBC-Treiber auch auf FireBird 3 zugreifen. Zumindest in Delphi 7 ist das kein Problem. Selbst über die BDE und ODBC sollte das noch hinzukriegen sein. Die  ODBC-Treiber sind auch nicht mehr die Neuesten, aber sie funktionieren auch noch mit FireBird 3.Klar, ein bisserl altertümlich und absolut nicht state of the art, aber eventuell eine Alternative. |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Zitat:
Gruß Kostas |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Grundsätzlich wäre dann gleich eine Migration auf die aktuelle 4er Version zu überlegen. Die Frage ist wohl, ob dann der Zugriff per IBObjects noch funktioniert.
|
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
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. und weitere tip zum ausprobieren: aktualisier einfach den fbclient auch auf die aktuelle version (ggf als gds32.dll kopieren und mit den anderen msv*.dll auf dem fb3 zip file in den pfad der alten exe kopieren) und versuch den zugriff mit deinen alten komponenten aus der alten exe. Wenn es echte probleme dann gibt, dann fast nur durch nicht mehr gültige SQL Befehle, die man dann halt ändern muss, wenn die nicht über relax alias checking lauffähig sein wenn du schreibst "geknallt", was meinst du da mit. ist der rechner explodiert? Gab es eine sichtbare Fehlermeldung, die von Firebird kommen könnte? ist das gleich sql auch mit externer tools wie ibexpert genau so ein problem? alternativ steht in der firbeird.log was drin? vieles lässt sich von altem kram mit firebird.conf relaxed alias checking beheben, aber ganz sicher nicht alles. Und delphi5 geht nicht mit fb3 halte ich für eine gerücht, ich kenne da eine ziemlich bekannte exe von uns die mit d5 compiliert ist und auch fb4 kann. wenn der fbclient zum server passt können auch alte projekte mit neueren fb versionen arbeiten |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
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. :-) |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Zitat:
Zitat:
|
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Zitat:
https://www.ibexpert.net/ibe/pmwiki....estoreDatabasewird 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 |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Zitat:
|
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Zitat:
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" |
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
[QUOTE=Delphi.Narium;1509397]
Zitat:
|
AW: FB 1.5 distinct bei varchar(2048) DB geht hops
Zitat:
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. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 23:18 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz