Inkompatibilitäten Firebird 5

[vr2]

.... die Verwendung von FB5 Client Bibliotheken für FB5 Server

das ist relativ egal, wenn Du nicht Feinheiten des APIs brauchst wie bspw zusätzliche role-Übergabe bei bestimmten Funktionen. Bzgl Performance spielt es keine Rolle. Erst wenn Du neue Features nutzen willst, wie bspw WireCompression, was wegen der Zeit für den Datentransport Auswirkungen auf die Gesamtperformance haben kann, wenn es über eine lahme Leitung gehen muss. Das kann ein legacy-Client dem Server nicht signalisieren. Aber die Kern-Ausführung eines Statements ist auch mit alten fbclients nicht langsamer. Und Neuerungen wie Statement Cache oder das experimentelle OptimizeForFirstRows sind ja ohnehin serverseitig, die kannst Du auch mit alten fbclients nutzen.

[martin.koeditz]

Grundsätzlich lohnt sich der Einsatz der neuen fbclients. Dann werden Fehlercodes korrekt übertragen.

Ich hatte alte fbclients mit FB 5.0-Server im Einsatz. Dann stießen wir auf kryptische ISC-Fehlercodes. Die kann man dann googeln. Besser ist jedoch, wenn man gleich eine aussagekräftige Meldung erhält.

Gruß
Martin

[RS667]

.... die Verwendung von FB5 Client Bibliotheken für FB5 Server

das ist relativ egal, wenn Du nicht Feinheiten des APIs brauchst wie bspw zusätzliche role-Übergabe bei bestimmten Funktionen. Bzgl Performance spielt es keine Rolle. Erst wenn Du neue Features nutzen willst, wie bspw WireCompression, was wegen der Zeit für den Datentransport Auswirkungen auf die Gesamtperformance haben kann, wenn es über eine lahme Leitung gehen muss. Das kann ein legacy-Client dem Server nicht signalisieren. Aber die Kern-Ausführung eines Statements ist auch mit alten fbclients nicht langsamer. Und Neuerungen wie Statement Cache oder das experimentelle OptimizeForFirstRows sind ja ohnehin serverseitig, die kannst Du auch mit alten fbclients nutzen.

Gut zu wissen, beides. Schön, hier so viel dazu zu lernen

[bfuerchau]

Zum Thema Timestamp noch eine Ergänzung:
Current_Timestamp liefert ja nun immer einen "Timestamp with Timezone", während Localtimestamp zwar ohne separate Timezone ist enthält sie aber die Serverzeitzone.
Eine UTC-Zeit ist allerdings aktuell mit Standardfunktionen nicht zu bekommen.
Ein Cast(<Timestamp with Timezone> as Timestamp) liefert allerdings nicht einfach den Timestamp sondern rechnet die Zeitzone wieder dazu. Da die Zeitzone nicht als Text sondern als +/- Wert bekannt ist, gibts kein Problem.
Umgekehrt wandelt ein Cast(<Timestamp> as Timestamp with Timezone) wird die Sessiontimezone wieder herausgerechnet und dann als Zeitzone angehängt.
Dies ist halt dann ein Problem, wenn die Zeitzone zwischen 1. Cast und 2. Cast unterschiedlich ist.
Möchte man nun vom Timestamp with Timezone tatsächlich nur die UTC-Zeit ist ein Cast über varchar erforderlich, z.B.:

cast(substring(cast(current_timestamp as varchar(48)) from 1 for 23) as timestamp)

Der innere Cast liefert einen ISO-String mit YYYY-MM-DD HH:MM:SS.FFFF +/-HH:MM.
Der Substring nimmt dann die ersten 23 Stellen, also incl. der 3-stelligen Millisekunden.
Der nächste Cast wandelt dann in einen Timestamp ohne dass eine Zeitzone berücksichtigt wird.

Somit erhält man nun mit obigem SQL die UTC-Zeit des Servers.
Bei der Verwendung in FB 3.0 erhält man auch hier allerdings nur wieder den Localtimestamp.