Inkompatibilitäten Firebird 5

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Benutzeravatar
RS667
Beiträge: 24
Registriert: Do 29. Aug 2024, 19:01

Hallo zusammen,

bei meinen Tests mit FB5 bin ich heute auf mehrere Errors gestoßen. Einer davon ist die Tatsache, dass ich beim Abruf des aktuellen Datums über

Code: Alles auswählen

select date 'now' from rdb$database
folgenden Error vom DBServer zurück bekomme:
Overflow occurred during data type conversion.
conversion error from string "Now".
----------------------------------------------
SQLCODE: -413
SQLSTATE: 22018
GDSCODE: 335544334

Das war in FB3.0.8 nicht so, da habe ich sauber das Datum zurück bekommen. Weiß Jemand, ob man diese "legacy-Funktion" irgendwie wieder aktivieren kann?


MfG Michael

edit: Das Ganze tritt sowohl mit der FB3.0 Client DLL auf, als auch mit der FB5.0
Benutzeravatar
RS667
Beiträge: 24
Registriert: Do 29. Aug 2024, 19:01

:ugeek:

These literal expressions are evaluated directly during parsing, as though the statement were already prepared for execution. As this produced unexpected or confusing results when using the datetime mnemonics like 'NOW', especially in PSQL code, the datetime mnemonics are no longer allowed in datetime literals since Firebird 4.0.

To use datetime mnemonics, use the full CAST syntax. An example of using such an expression in a trigger:

NEW.CHANGE_DATE = CAST('now' AS TIMESTAMP);
bfuerchau
Beiträge: 546
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Du wirst auch auf ein Problem stossen, wenn du "current timestamp" abfragst.
Seit 4.0 liefert das den neuen Type "Timestamp with timezone".
https://firebirdsql.org/file/documentat ... etime.html
Leider ist der Default für Timestamp immer with timezone, was zu Inkompatibilitäten führt. Andere DBM's nutzen die die Timezone nur, wenn sie explizit verlangt wird.
Benutzeravatar
RS667
Beiträge: 24
Registriert: Do 29. Aug 2024, 19:01

bfuerchau hat geschrieben: Di 3. Sep 2024, 19:37 Du wirst auch auf ein Problem stossen, wenn du "current timestamp" abfragst.
Seit 4.0 liefert das den neuen Type "Timestamp with timezone".
https://firebirdsql.org/file/documentat ... etime.html
Leider ist der Default für Timestamp immer with timezone, was zu Inkompatibilitäten führt. Andere DBM's nutzen die die Timezone nur, wenn sie explizit verlangt wird.
Gut zu wissen, danke. Dumm ist, dass die Sofware, die wir einsetzen, closed source Delphi ist, wir sind also auf den hersteller angewiesen, das zu umgehen. Weißt Du, ob man den Server irgenwie anweisen kann, diesen Default abzuschalten? Ich hatte in den firebird.conf Settings gesucht, aber bin noch nicht fündig geworden :/

MfG Michael
bfuerchau
Beiträge: 546
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Nein, das gibts nicht. Es gibt wohl Ersatzfunktionen, die man nun in aktuellen 2.5 oder 3.0 verwenden soll, damits mit 4.0ff klappt.
Wenn die Software nicht anpassbar ist, kannst du nicht auf 4.0/5.0 wechseln.
So einfach ist das. Ich stehe vor demselben Problem.

https://github.com/FirebirdSQL/firebird/issues/6113
vr2
Beiträge: 246
Registriert: Fr 13. Apr 2018, 00:13

Doch das gibts. Seit FB4 gibt es den Kompatibiltätsschalter DataTypeCompatibility in der firebird.conf, mit dem einige Datentypen, u.a. timestamps, serverweit zu ihren älteren Entsprechungen runtergestuft werden können. Der wird in https://www.firebirdsql.org/file/docume ... ement.html im Kasten "Tip" erklärt. Das reicht u.U. nicht ganz, muss aber in jedem Fall gemacht werden, wenn Du Altanwendungen mit FB4 oder FB5 betreiben bzw keine Zeitzonen haben willst. Dann ist zu unterscheiden, ob in der Datenbank oder der Anwendung geändert werden muss, Vorkommen von current_timestamp durch localtimestamp ersetzen. Wenn ihr die DB ändern könnt, kann es sein, dass das schon reicht. Wenn die closed source Anwendung geändert werden muss, kann man dem Hersteller nur schreiben, Leute, ihr supportet lediglich eine 14 Jahre alte Datenbankversion, die längst aus der Wartung raus ist, wollt ihr da nicht mal was machen? Die fbclient spielt bei dem Ganzen übrigens keine Rolle, die muss nur weiterhin zur Client-SW passen, hat mit dem Server in dem Fall nichts zu tun, da der ja auf legacy konfiguriert wird.

Michael, such mal hier im Forum nach Beiträgen mit localtimestamp. Hauptsächlich:

viewtopic.php?f=5&t=251
viewtopic.php?f=11&t=338&p=2056&hilit=l ... tamp#p2056

Da beschreibe ich, was man machen muss. Es gibt zwei knifflige Bereiche bei der Umstellung von FB2.5/3 auf FB4 oder 5, das sind timestamps und Umzug der User, falls deren Passwörter mitumziehen sollen. Für beides gibt es Verfahren.

Wenn es Fragen gibt oder anschließend noch was hängt, schreib bitte hier rein.
bfuerchau
Beiträge: 546
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Sehr schön, dann erreicht man ja mit dem Kompatibilitätsschalter den Standard der anderen DBM's und kann frei entscheiden, ob man DB-Timezones überhaupt benötigt.
Denn Zeitzonen gibts schon immer und das gängige Verfahren seit fast 50 Jahren IT meinerseits ist: Speichern des Timestamps in UTC, was immer schon möglich ist.
Das Umrechnen in die Zeitzone des Users erfolgt im jeweiligen Client mit der aktuellen Zeitzone via ToLocaltime-Funktion, die UTC + aktuelle Zeitzone berücksichtigt.
Eine Speicherung der TZ ist nicht unbedingt erforderlich, da die UTC für Sortierungen, Berechungen usw. vollkommen ausreicht.
Zumal ja nun die DB meist auf einem Server läuft, den man in die Zone GMT+0 stellen kann.
Mit dem neuen Timestamp schafft man in der Software-Entwicklung eher Verwirrung, da man ja je Verbindung erst mal die Zeitzone des Users erfahern muss. In einer Web-Anwendung stellt der Web-Server die Verbindung und kann via IP-Adresse die TZ nicht erfahren.
Und JavaScript o.ä. unterstützen für die Anzeige im Client auch die Umwandlung von UTC in Localtime. Das ist seit Jahrzehnten schon Standard.
Abe das ist meine ganz persönliche Meinung 8-) .
Benutzeravatar
RS667
Beiträge: 24
Registriert: Do 29. Aug 2024, 19:01

vr2 hat geschrieben: Mi 4. Sep 2024, 02:07 Doch das gibts. Seit FB4 gibt es den Kompatibiltätsschalter DataTypeCompatibility in der firebird.conf, mit dem einige Datentypen, u.a. timestamps, serverweit zu ihren älteren Entsprechungen runtergestuft werden können.

Die fbclient spielt bei dem Ganzen übrigens keine Rolle, die muss nur weiterhin zur Client-SW passen, hat mit dem Server in dem Fall nichts zu tun, da der ja auf legacy konfiguriert wird.

Michael, such mal hier im Forum nach Beiträgen mit localtimestamp. Hauptsächlich:

viewtopic.php?f=5&t=251
viewtopic.php?f=11&t=338&p=2056&hilit=l ... tamp#p2056

Da beschreibe ich, was man machen muss. Es gibt zwei knifflige Bereiche bei der Umstellung von FB2.5/3 auf FB4 oder 5, das sind timestamps und Umzug der User, falls deren Passwörter mitumziehen sollen. Für beides gibt es Verfahren.

Wenn es Fragen gibt oder anschließend noch was hängt, schreib bitte hier rein.
Hallo,

danke für die schnelle Antwort. Die nicht mehr kompatible, von der betreffenden Software verwendeten Software verwendete Abfrage fixt das leider nicht:

Overflow occurred during data type conversion.
conversion error from string "now".
----------------------------------------------
SQLCODE: -413
SQLSTATE: 22018
GDSCODE: 335544334

Was die client library und den legacy mode angeht, das weiß ich. Ich habe aber die naive Annahme, dass das native besser sein sollte.

Ich hau mal den Softwarehersteller an, und lese mir noch ein bisschen die verlinkten Threads durch. Gutes Forum bisher!

MfG Michael
vr2
Beiträge: 246
Registriert: Fr 13. Apr 2018, 00:13

RS667 hat geschrieben: Mi 4. Sep 2024, 10:08 [...] Die nicht mehr kompatible, von der betreffenden Software verwendeten Software verwendete Abfrage fixt das leider nicht:

Code: Alles auswählen

select date 'now' from rdb$database
Overflow occurred during data type conversion.
conversion error from string "now".
Ja, der Schalter DataTypeCompatibility deckt nicht die Änderung ""datetime mnemonics are no longer allowed in datetime literals since Firebird 4.0." ab. Ich hab die Problematik an die Firebird-Stiftung weitergegeben, und der aktuelle Präsi hat auch gleich geantwortet - der Zeitpunkt war passend, sie hatten erst vor einigen Tagen aufgerufen, auf FB5 upzudaten, und ich hab beschrieben, warum etliche das nicht tun (können). Mit DataTypeCompatibility = 3.0 liefert ein FB4 oder FB5 selbst bei

Code: Alles auswählen

select current_timestamp from rdb$database 
einen timestamp ohne TZ . Soweit ja gut.

Mal sehen, ob sie für die Restriktionen bzgl datetime mnemonics auch eine Lösung anbieten können, damit nicht jeder Einzelne seinen closed-source-SW-Hersteller hinter sich herziehen muss. Und wenn der dann nur auf FB3 geht, hat man kaum was gewonnen.

Bzgl Userumzug wollen sie bessere Erklärungen des Ablaufs bringen - ich fand die nicht übel, aber nur erfahrene Anwender trauen sich zu Fuß da ran, daher hab ich eine utility-Funktion für den Userumzug angeregt.
Was die client library und den legacy mode angeht, das weiß ich. Ich habe aber die naive Annahme, dass das native besser sein sollte.
Was meinst Du hier mit native?

Viele Grüße, Volker
Benutzeravatar
RS667
Beiträge: 24
Registriert: Do 29. Aug 2024, 19:01

Hallo,

Ich meine die Verwendung von FB5 Client Bibliotheken für FB5 Server, nicht den legacy user Mode.

MfG Michael
Antworten