SQL-Abfrage funktioniert nur bedingt

[harfes]

Hallo,

ich benutze folgende SQL-Abfrage, um Daten aus einer Tabelle für einen bestimmten Zeitraum zu bekommen:

select * from PLANUNG where ITEMBEGIN>='01.11.2016' AND ITEMEND<='30.11.2016';

Das Problem: Tabelleneinträge mit Datum 01.11. werden erfasst (>= funktioniert also), Einträge vom 30.11. aber nicht - keine Ahnung, warum das so ist???? Die Befehlssyntax müsste richtig sein, denn wenn ich ITEMEND=<'30.11.2016' schreibe, bekomme ich einen SQL-Fehler.

Hat da jemand eine Idee, was da falsch läuft?

Hartmut

[jobo]

Schau Dir mal hier im Forum, wie man Abfragen parametriert und dabei den Datentyp der Spalte berücksichtigt.
Du verwendest Strings an Stelle eines Datums, dabei kann nichts Gutes rauskommen.

Zu dem Thema müsste es dutzende Posts geben.

[alex517]

Welchen Type hat denn ITEMEND?
Wenn es TimeStamp ist, dann werden nur Datensätze ITEMEND <= '30.11.2016 00:00' angezeigt.
Entweder du verwendest DATE als Typ oder ITEMEND < '01.12.2016'.

[hoika]

Hallo,

bekomme ich einen SQL-Fehler.

Schön, welcher das ist, wäre zur Lösung der Aufgabe sehr hilfreich.
Alles andere (Parameter, <EndDatum+1) wurde ja bereits gesagt.
Ah nein, >StartDatum-1 hatte gefehlt ...

[Jasocul]

Zitat:

Zitat von hoika (Beitrag 1354991)

Ah nein, >StartDatum-1 hatte gefehlt ...

Na, noch nicht ausgeschlafen? :wink:
Das ist natürlich falsch. Das Problem ist bei diesem klassischen Fehler nur beim End-Datum.
Lösungen dafür wurden schon beschrieben.

Man kann natürlich auch in der Anwendung dafür sorgen, dass wirklich nur das Datum ohne Uhrzeit gespeichert wird. Aber dann müsste zusätzlich auch die Tabelle bereinigt werden. Der Aufwand dürfte da dann aber zu groß werden.

[Lemmy]

darüber hinaus wäre auch noch zu beachten ob es überhaupt gültige Datensätze gibt, bei denen beide Bedingungen erfüllt sind - immerhin handelt es sich hier um 2 Spalten

[alex517]

Man könnte auch

Code:

CAST(ITEMEND as DATE) <='30.11.2016'

verwenden.
Das hätte aber zur Folge, dass ein evt. vorher vorhandener und verwendeter Index auf ITEMEND von FB
nicht mehr verwendet wird.
Ob das von Nachteil ist muss im Einzelfall geprüft werden.

[EmWieMichael]

Zitat:

Zitat von harfes (Beitrag 1354987)

...
Die Befehlssyntax müsste richtig sein, denn wenn ich ITEMEND=<'30.11.2016' schreibe, bekomme ich einen SQL-Fehler.
...

Die Syntax ist ja auch korrekt ("=<" ist es nicht). Wenn Du Datumsfelder als String vergleichen willst, musst Du sie umgekehrt abbilden, also jjjjmmtt; eleganter ist allerdings die Verwendung von entsprechenden Datumtypen der Datenbank.

[p80286]

Oh,
ich nahm an

Delphi-Quellcode:

Datum>='30.11.1977'

ist die Möglichkeit ein Datum im länderspezifischen Format zu übergeben??
Es gibt ja Datenbanken, die so etwas angeblich können. Um Mißverständnissen vorzubeugen, Es ist immer sauberer mit Datumswerten zu arbeiten.

Gruß
K-H

[alex517]

Zitat:

Zitat von p80286 (Beitrag 1355019)

Oh,
ich nahm an

Delphi-Quellcode:

Datum>='30.11.1977'

ist die Möglichkeit ein Datum im länderspezifischen Format zu übergeben??
Es gibt ja Datenbanken, die so etwas angeblich können. Um Mißverständnissen vorzubeugen, Es ist immer sauberer mit Datumswerten zu arbeiten.

Firebird versteht auch das länderspezifische Datums-Format.
'yyyy-mm-dd' geht aber immer, wenn schon mit Strings gearbeitet wird.

[Edit]
Aussage "versteht auch das länderspezifische Datums-Format" ist nur teilweise richtig
siehe hier http://www.firebirdfaq.org/faq137/

[jobo]

Die Angabe eines lokalisierten (länderspezifischen) Strings, der ein Datum enthält, funktioniert nur dann, wenn die Clientsession dieses Format eingestellt hat. Das wird idR grundsätzlich erstmal erreicht, wenn ein Setupprogramm bei der Installation des DB Client diese Ländereinstellung des OS erkennt und zur Verwendung durch den DB Client einstellt.
Das betrifft die Parameterangabe als Text.

Dann gibt es noch die DB Seite mit dem zu vergleichenden Feld, die natürlich dann auch vom Typ Date sein sollte, häufig aber aus Unkenntnis oder Faulheit ebenfalls als String deklariert ist und einen sauberen Vergleich unnötig erschwert.

Letztlich stellt sich mir immer die Frage, warum gerade Delphi Entwickler, denen der Begriff eines Datentyps nicht fremd sein sollte, an dieser Stelle immer so rumeiern.
Warum lege ich mir also an der Stelle (bewusst) ein Überraschungsei in Nest, wenn ich weiß, dass die Funktion der Abfrage mehr oder weniger nur Zufall ist (weil sie von den Systemeinstellungen abhängt).

[harfes]

Danke für die vielen Anregungen. Die Lösung ist, dass das DB-Feld ein TDateTime ist (und es werden sogar Uhrzeiten gespeichert, die aber für die Monatsabfrage keine Rolle spielen) und somit <=datum+1 funktioniert - danke Alex517. Und ja, die Werte werden als Parameter übergeben - in meiner Anfrage hier hatte ich die nur als String dargestellt, um das Problem (vermeintlich?) besser darstellen zu können...

Hartmut

[haentschman]

Moin...8-)

Zitat:

um das Problem (vermeintlich?) besser darstellen zu können...

...das war ein Trugschluß. :P Die Parameter sind eine wichtige Information um das ganze SQL Statement beurteilen zu können. Die Übergabe der Parameter an das Statement ist eine andere "Abteilung". :thumb:

[p80286]

Zitat:

Zitat von jobo (Beitrag 1355026)

Letztlich stellt sich mir immer die Frage, warum gerade Delphi Entwickler, denen der Begriff eines Datentyps nicht fremd sein sollte, an dieser Stelle immer so rumeiern.

Zum einen weil viele Datenbanken(-Einführungen) hier auch herum eiern und Typen hinter irgendwelchen Format-Funktionen versteckt werden. Ähnlich verhält es sich mit den verwendeten Zeichensätzen, die sowohl da als auch da und in Kombination, aber vielleicht auch ganz anders verwendet werden.

Gruß K-H

[Mokus]

Je nachdem welche Server Erosion du hast, empfehle ich einfach die Funktion between.
Damit hätte ich nie diese Probleme. Und du hast das konvertieren nicht, dass wieder performance kostet ( auf Funktionen kann kein Index angewendet werden) somit läuft es auf ein table scan hinaus ... ;)