SQL-Abfrage langsam?

[haentschman]

Moin...

Zitat:

Uhrzeit ist vom Typ Date in der Datenbank.

Delphi-Quellcode:

SELECT DATUM, UHRZEIT, TEMPSENSOR_1, FEUCHTESENSOR_1 FROM Wetterdaten WHERE DATUM = '12.05.2017' ORDER BY UHRZEIT
.

...und warum übergibst du trotzdem das Datum als string? Damit die DB das casten muß?

[himitsu]

Parameter?

Code:

WHERE DATUM::VARCHAR = '12.05.2017'
WHERE DATUM = '12.05.2017'::DATE

Wie rum Castet die DB eigentlich, bei sowas?

[haentschman]

Zitat:

Parameter?

...versteht sich von allein. Manchmal hätte ich einen virtuellen "MÖÖÖP" mit rotem Knopf wenn ich sowas sehe...

[bnreimer42]

Zitat von himitsu:

Parameter?

Code:

WHERE DATUM::VARCHAR = '12.05.2017'
WHERE DATUM = '12.05.2017'::DATE

Wie rum Castet die DB eigentlich, bei sowas?

Wenn es geht, in Richtung Datentyp der Tabellenspalte.

Wäre anderenfalls zu langsam, weil jedes Feld erst konvertiert werden müsste. Den Parameter oder die Konstante in der Where-Bedingung muss ja nur einmalig umgewandelt werden.

[Helmi]

Zitat von haentschman:

...und warum übergibst du trotzdem das Datum als string? Damit die DB das casten muß?

mmmh - irgendwie hatte ich im Hinterkopf, dass Firebird bei Abfragen keine Parameter erlaubt/will/kann.

Nach nem Test funktioniert es aber doch

[mkinzler]

Zitat:

mmmh - irgendwie hatte ich im Hinterkopf, dass Firebird bei Abfragen keine Parameter erlaubt/will/kann.

Nicht für Tabellen-/Feldnamen. Aber für Werte schon.

[himitsu]

Zitat von mkinzler:

Nicht für Tabellen-/Feldnamen. Aber für Werte schon.

Da verwende ich dann Macros mit einem clientseitigem quote_ident.

[Helmi]

Zitat von mkinzler:

Zitat:

mmmh - irgendwie hatte ich im Hinterkopf, dass Firebird bei Abfragen keine Parameter erlaubt/will/kann.

Nicht für Tabellen-/Feldnamen. Aber für Werte schon.

ok - Danke!
Ich hatte, meines Erachtens nach, schon mal für Werte getestet - was dann in einem Fehler endete, daher diese String-Geschichte