Datumsvergleich bei Parameterabfrage mit firebird

[Heiko]

Hallo,
bei der Umstellung von einer internen hsql-DB auf eine externe firebird-DB bin ich bei einer Abfrage auf ein Problem gestoßen, das ich nicht gelöst bekomme:
Firebird 3
LO 24.8.2.1
Ziel ist es, in einem Formular Datensätze danach filtern zu können, ob sie vor oder nach einem Datum liegen. Ich habe also eine Filtertabelle mit u.a. zwei Datumsfeldern je eines für die Abfrage des ">=" und des "<=". In der alten DB mit hsql hatte ich diese WHERE-Klauseln:
... AND ( "datbeet" <= :qkldatbeet OR :qkldatbeet IS NULL ) AND ( "datbeet" >= :qgrdatbeet OR :qgrdatbeet IS NULL )
Leider bekomme ich immer die Fehlermeldung "Incorrect type for setString"
Das ändert sich auch nicht, wenn ich den Datentyp der Parameter klarstelle:
( "datbeet" <= CAST(:qkldatbeet AS DATE) OR :qkldatbeet IS NULL ) AND ( "datbeet" >= CAST(:qgrdatbeet AS DATE) OR :qgrdatbeet IS NULL )
Ich habe es auch schon mit DATEDIFF versucht, sobald ich Parameter einsetze, kommt o.g. Fehlermeldung.
Was mache ich falsch?
Viele Grüße
Heiko

[RobertG]

Ich habe das gerade einmal mit einer internen DB getestet:

Code: Alles auswählen

SELECT * FROM "tbl_Test" WHERE "Datum" <= :qDat

funktioniert hier unter Version: 24.8.3.2 (X86_64) einwandfrei mit Firebird zusammen.
Da geht es wohl mehr um die Konstruktion mit "OR :qDat IS NULL", oder?

Code: Alles auswählen

SELECT * FROM "tbl_Test" WHERE "Datum" <= :qDat OR CAST(:qDat AS VARCHAR(50)) IS NULL

Habe ich so aus dem Kapitel zu Parameterabfragen aus dem aktuellen Handbuch.

[Heiko]

Guten Morgen Robert,

den Passus aus dem Handbuch hatte ich gelesen. Allerdings habe ich bei einer anderen Abfrage festgestellt, dass dort die Parameter korrekt funktionieren, wenn ich es folgendermaßen formuliere:
( "kultverf"."kultur" = CAST(:qkultur AS INTEGER) OR :qkultur IS NULL )

Hier fragt der Parameter nach der ID, ein INTEGER-Feld. Ohne das CAST kommt der genannte Fehler.

Die Frage nach einem BOOLEAN-Feld habe ich so zum Laufen gebracht:
( "kultverf_aktiv" = CAST(:qaktiv AS VARCHAR(10)) OR :qaktiv IS NULL )

LO habe ich mal auf 24.8.3.2 aktualisiert, dann ist das besser vergleichbar.

Zu meiner Datum-Abfrage:

"daternteende" <= :qkldaternteende
funktioniert, wenn ich ein Datum eingebe, bei NULL bleibt die Tabelle leer.

( "daternteende" <= :qkldaternteende OR CAST(:qkldaternteende AS VARCHAR(50)) IS NULL )
bei NULL ist die Tabelle gefüllt, bei Datumseingabe kommt die Fehlermeldung "Incorrect type for setValue"

( "daternteende" <= CAST(:qkldaternteende AS DATE) OR CAST(:qkldaternteende AS VARCHAR(50)) IS NULL )
bei NULL ist die Tabelle gefüllt, bei Datumseingabe kommt die Fehlermeldung "Incorrect type for setString"

( "daternteende" <= :qkldaternteende OR :qkldaternteende IS NULL )
bei NULL ist die Tabelle gefüllt, bei Datumseingabe kommt die Fehlermeldung "Incorrect type for setValue"

( "daternteende" <= CAST(:qkldaternteende AS DATE) OR :qkldaternteende IS NULL )
bei NULL ist die Tabelle gefüllt, bei Datumseingabe kommt die Fehlermeldung "Incorrect type for setString"

( "daternteende" <= CAST(:qkldaternteende AS VARCHAR(50)) OR :qkldaternteende IS NULL )
sowohl bei NULL, als auch bei Datumseingabe erfolgt eine korrekte Filterung und Anzeige der Daten. Diese Variante hatte ich zuvor tatsächlich noch nicht versucht, denn ich finde es nicht logisch, dass ich die Datumseingabe zu einem VARCHAR machen muss. Denn es funktioniert, egal ob ich 10.10.25 oder 2025-10-10 eingebe.

Jetzt funktioniert es bei mir allerdings genau umgekehrt, wie im Handbuch beschrieben. Ist das nur hier so, oder lassen sich die Ergebnisse auf einem anderen System so wiederholen?

Könnte soetwas auch an der Verbindung zur DB liegen? Ich habe den Firebird-Treiber gewählt, es gingen ja auch JDBC oder ODBC?

Viele Grüße
Heiko

[RobertG]

Das Merkwürdige ist doch eigentlich, dass bei Parametern die Eingabe selbst erst einmal eine reine Texteingabe ist. Ich muss mir das erst einmal genauer anschauen. Auch dazu gab es Bugmeldungen. Mir fällt so etwas nicht auf, weil ich mit Parametern überhaupt nicht arbeite.

Schau einmal hier: https://bugs.documentfoundation.org/sho ... ?id=130595

Vielleicht müssen wir da einen Folgebug zu auf machen.
Edit: Habe ich gemacht: https://bugs.documentfoundation.org/sho ... ?id=163996

Gruß

Robert