FB 1.5 distinct bei varchar(2048) DB geht hops

[Kostas]

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

[himitsu]

"Ü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)

[mkinzler]

Bis zu einer Länge von 32KB bestehr bei FireBird eigentlich kein Unterschied zwischen eine CLOB un Varchar

[Kostas]

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.

[Rolf Frei]

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.

[Kostas]

Zitat:

Zitat von Rolf Frei (Beitrag 1509338)

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.

vielen lieben Dank, aber es sind noch weitere Komponenten. Ich müsste vorher in Delphi 5 die Komponenten ersetzen durch kompatible. Das ist so viel Arbeit, es ist fast unmöglich. Noch zudem sind das individuelle Kunden-Anwendungen. Aber gut zu wissen dass es evl. eine Möglichkeit gäbe.

Gruß
Kostas

[Delphi.Narium]

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.

[Kostas]

Zitat:

Zitat von Delphi.Narium (Beitrag 1509341)

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

[mkinzler]

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.

[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.

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