Datum, SQL Abfrage
-
Also erstmal... ist der Datentyp der Spalte die du prüfst auch "datetime" (bzw. "smalldatetime")? Wenn nicht, dann konvertiere die Spalte nach datetime. Entweder permanent in der Tabelle, oder nur für den Vergleich in der Abfrage. (Bei der 2. Möglichkeit kann SQL Server die Abfrage dann allerdings nichtmehr über einen Index auf diese Spalte optimieren -- wenn das Datum die "selektivste" Filterbedingung ist wäre diese Variante also nicht so gut)
Wenn schon, kann ich mir echt nicht vorstellen, was das Problem sein könnte. MS SQL Server erkennt das Format "yyyy-mm-dd" zuverlässig, egal was für ein Datumsformat "eingestellt" ist. "yyyy-mm-dd" kann man schon anhand der position der "-" nicht mit "dd-mm-yyyy" verwechseln, und da es auch kein "yyyy-dd-mm" format gibt, wird "yyyy-mm-dd" *immer* korrekt erkannt. Natürlich nur wenn es eine implizite Konvertierung nach "datetime" gibt, also z.B. wenn man diesen String mit einer "datetime" Spalte vergleicht.
Wenn du so einen String mit einer anderen String (char/varchar/nchar/nvarchar) vergleichst, dann kommt in der "dd-mm-yyyy" Version natürlich blödsinn raus. Das ist auch einer der Vorteile des "yyyy-mm-dd" Formats: man bekommt mit einem String-Vergleich dasselbe Ergebnis wie mit einem Datums-Vergleich.
-
@ARoh
mich würde trotzdem interessieren wie du im Quelltext die Datumswerte an das Query übergibst, eventuell liegt da ja eher das Problem bzw. die Lösung
-
Werden in den Datumsangaben auch Zeitinformationen mitgeführt? Wenn ja musst Du Dich nicht wundern wenn jeweils der letzte Tag fehlt.
-
Hi Zusammen,
danke für die zahlreichen Antworten.
Zunächst einmal habe ich es ausprobiert ob das Problem auch mit Access auftritt.
Folgende Abfrage / Sicht habe ich auf den SQL Server losgelassen:SELECT [Index], Kassennummer, Buchungskonto, Kassierer_ID, Mandant_ID, Zahlung_Scheck_EC, Waehrung, Rechnungsbetrag_Euro, Rechnungsbetrag, Rechnungsdatum, Rechnungsnummer, Kundenname, Kundennummer, Datum_Str, Datum
FROM dbo.Rechnungzahlung WHERE (Datum >= CONVERT(DATETIME, '2008-12-01 00:00:00', 102)) AND (Datum <= CONVERT(DATETIME, '2008-12-03 00:00:00', 102))Und auch diverse andere Abfragen bringen mich nicht weiter. Diese Abfrage habe ich im Übringen "zusammengeklickt" Das Ergebnis ist ähnlich, es werden noch weniger Einträge zurückgegeben. Insofern @Linnea es kann kein Programmiertechnisches Problem sein und @hustbaeres ist die Spalte bereits datetime und nicht smalldatetime. Aber weil es so nett ist, habe ich noch eine Spalte angehängt vom Typ smalldatetime und die Daten aus der Spalte Datum umkopiert, aber auch das brachte keine Besserung. Da es im Grunde nichts mit der Umgebung zu tun hat (C++ sowie Access) liegt der Fehler meines Erachtens am SQL Server. Dem widerspricht, dass ich das Problem auch mit einem anderem Server schon früher hatte. Hmmmm Wo liegt das Problem? Das einzigste ist immer dass der abfragende Rechner gleich ist (und der davor sitzt...) .... Aber mein Rechner arbeitet mit alles anderen SQL-Programmen sauber und ohne Probleme.
Gruss
Achim
-
Hast du mal versucht das Query ohne Umweg über Access oder ähnliches auszuführen? z.B. mittels OSQL?
Das Problem mit dem Datum kenne ich bei MSSQL auch, allerdings lag es dort immer daran, dass ich bei den verwendeten Datenbankkomponenten (ADO im BCB6) versucht habe Werte zu übergeben, bei denen ich bei der Übergabe noch Berechnungen getätigt habe. Das führte dann zum Fehlen von genau 2 Tagen bei den Ergebnissen. Im Management Studio oder per OSQL kamen allerdings immer die kompletten Werte zurück bzw. die Datumskonvertierung funktionierte einwandfrei. Deshalb frage ich nach dem Quellcode bzw. jetzt nach der Programmierumgebung.
-
Wenn die Spalte schon datetime ist sehe ich keine Möglichkeit wie das schief gehen sollte.
Natürlich ist es theoretisch immer möglich dass SQL Server einen Bug hat, aber die Wahrscheinlichkeit eines Bugs dieser Art ist sehr sehr gering.
Versuch mal mit dem Management Studio das Problem nachzustellen, also ein kurzes Script welches eine Tabelle erstellt, ein paar Zeilen einfügt, und dann das Select macht wo Unfug rauskommt.
-
Hallo,
so ich habe die Probleme gefunden:
Ich habe die Abfrage über den Enterprisemanager / Query - Analyser getestet und musst auch da feststellen, dass die Abfrage mangelhaft war.
Erst mit der Angabe der Zeit (2008-12-01 00:00:00:00 und 2008-12-03 23:59:59:00 ) gab es vernünftige Ergebnisse. Das war im Grunde alles... Ich wollte mir die Abfrage mit der Zeit sparen, aber wenn es so sein muss, ist es so.Viele Grüße und Danke für Eure Ideen, die waren hilfreich.
Achim
-
Oha, sorry, ich hatte übersehen dass du <= verwendest, das kann natürlich nicht klappen.
Die Zeit brauchst du trotzdem nicht, mach einfach >= 2008-12-01 AND < 2008-12-04 (also den Tag DANACH!).Ohne Angabe der Zeit wird einfach immer 00:00:00.000 als Zeit angenommen. Da beim Vergleich aber immer die genaue Zeit verglichen wird, fehlt dir bei <= 2008-12-03 der ganze letzte Tag (2008-12-03 00:00:00 besteht den Test, 2008-12-03 00:00:01 schon nichtmehr).
-
Oh Mann, du hast Recht.... Da habe ich geschlafen, irgendwie wird man betriebsblind wenn man ewig einen Fehler sucht.
Danke Dir
-
Gerne
Ich war diesmal auch selber ziemlich blind -- hätte das eigentlich merken müssen...
Egal, jetzt weisst du ja wie's geht.
