An Von/Bis Datumsfunktion gescheitert

[iO-usw]

Okay, also folgendes Problem: Ich wollte nur eine langweilige Von/Bis Datumsfunktion einfügen. Aber irgendwie bekomme ich das nicht gebacken. Aber irgendwie bekomme ich die nicht gebacken. Irgendwann kurzfristig hatte die mal geklappt (als ich was aus dem Internet gesaugt hatte) aber da bekam ich keine gültigen Daten, sondern nur Müll (wegen US-Datumsformat??).

Also... ich bin jetzt schon so verzweifelt, das ich einfach Daten in Variablen gepackt habe. Den Datentyp hatte ich auch schon auf Integer oder String, hat aber nie funktioniert. VDatum ist vom (Tabellen)Typ Datum.

Code (vb) [Auswählen] Erweitern


'VarDat3 As Date
'VarDat4 As Date
'VarDat3 = "10.10.2011"
'VarDat4 = "01.10.2014"
'CurrentDb.Execute ("INSERT INTO TblSpeicher(Projekt) " & "SELECT * FROM TblEingabe WHERE VDatum BETWEEN '& VarDat3 &' AND '& VarDat4 &'")

EDIT: Also ich bekomme regulär meistens Fehlermeldungen, das die Dateitypen unverträglich sind. Hab auch schon alles mögliche ausprobiert, auch mit string und integer, ohne das ich Erfolg hatte.

[MaggieMay]

Hallo,

Datumswerte bedürfen für den Einsatz in SQL einer bestimmten Formatierung.
Versuche es mal hiermit:

Code [Auswählen] Erweitern

Dim strSQL As String
strSQL = "INSERT INTO TblSpeicher (Projekt) " & _
              "SELECT * FROM TblEingabe " & _
              "WHERE VDatum BETWEEN " & Format(VarDat3, "\#mm\/dd\/yyyy\#")  & _
                                             " AND " & Format(VarDat4, "\#mm\/dd\/yyyy\#")
CurrentDb.Execute strSQL, dbFailOnError

[iO-usw]

Houston wir haben da ein kleines Problem.

Funktioniert schon, soviel ich überprüfen kann, aber die Daten stimmen nicht. Er hat auch Daten vom 31.03.2014 und ähnliches.

Vielleicht habe ich mich getäuscht, ich wollte aber zeitgleich eine erste Rückmeldung geben. Denn diesen Fehler hatte ich bereits gehabt.

[MaggieMay]

Er hat auch Daten vom 31.03.2014 und ähnliches.

Was wunderst du dich denn da, bei der Datumsvorgabe?! 

[MzKlMu]

Hallo,
wenn da wirklich 31.03.2014oder ähnliches drin steht, kann der Datumsvergleich mit BETWEEN nicht funktionieren, denn das Feld ist dann kein Datumsfeld sondern ein Textfeld unbd es wird Text verglichen was nicht stimmen kann, bzw. nur bei oberflächlicher Prüfung stimmt.
Wenn das Feld vom Typ Datum/Zeit wäre, wäre die Speicherung von 31.03.2014 nicht möglich.
Daher ist es unabdingbar notwendig die Datumswerte zu bereinigen und das Feld auf Datum/Zeit umzustellen. Erst dann können die Daten angefügt werden.

[iO-usw]

Ich fühlte mich einen Moment blöd, bis ich herausfand, das er auch Daten vom 24.10.2014 anzeigte.

An MzKlMu: Das habe ich ja auch schon gelesen. Die Variablen sind vom Typ Date und das Tabellenfeld auch. (siehe den obigen Code)
Muss ich da irgendwas sonst beachten?

[DF6GL]

Hallo,

VarDat3 As Date
VarDat4 As Date
VarDat3 = "10.10.2011"
VarDat4 = "01.10.2014"

sollte Dir zu denken geben....


So wird es was:

Code [Auswählen] Erweitern

Dim VarDat3 As Date, VarDat4 As Date, strSQL As String

VarDat3 = #10/10/2011#
VarDat4 = #10/01/2014#

strSQL = "INSERT INTO TblSpeicher  " & _
              "SELECT * FROM TblEingabe " & _
              "WHERE VDatum BETWEEN " & Format(VarDat3, "\#mm\/dd\/yyyy\#")  & _
                                             " AND " & Format(VarDat4, "\#mm\/dd\/yyyy\#")
CurrentDb.Execute strSQL, dbFailOnError

[iO-usw]

Hallo DF6GL,
ja es hat mir zu denken gegeben, aber mir fiel nie eine gute Alternative ein.

Außerdem muss ich noch irgendwo einen anderen Fehler haben, weil er keine Änderung in der Tabelle übernimmt.

Ich mache am besten nach Weihnachten weiter...ich wünsche euch noch ein frohes Fest.

[DF6GL]

Hallo,

siehe meinen korrigierten letzten Post..


wobei "keine Änderungen übernimmt" nicht zu der Insert-Abfrage passt...

[MzKlMu]

Hallo,
wenn es Datumswerte 31.03.2014 in der Quelltabelle (TblEingabe) gibt, dann kann dieses Feld kein Datumsfeld sein, sondern muss Text sein. Und dann muss zwangsläufig das Kriterium mit BETWEEN schief gehen, denn es wird die reine Zeichenfolge herangezogen.
Nach meiner Auffassung müssen erst mal die Datumswerte so bereinigt werden, dass kein ungültiges Datum in der Quelltabelle vorhanden ist. Unabhängig vom Datentyp der Zieltabelle der natürlich Datum ist.

[MaggieMay]

Hallo,

wenn es Datumswerte 31.03.2014 in der Quelltabelle (TblEingabe) gibt, dann kann dieses Feld kein Datumsfeld sein

wie kommst du da drauf?

die Daten stimmen nicht. Er hat auch Daten vom 31.03.2014 und ähnliches.

Für mich liegt der 31.3.2014 zweifelsfrei in dem von dir gewählten Zeitraum vom 10.10.2011 bis zum 1.10.2014.

Kann es sein, dass das Problem vor dem Monitor sitzt? ;-)

[MzKlMu]

Hallo,
sorry, für die Verwirrung. Irgendwie war ich der Meinung der März hätte nur 30 Tage. Meine Beiträge in diesem Thema waren daher grad für die Katz. 

[MaggieMay]

Aber auch Franz war auf dem falschen Dampfer, denn diese Zeilen sind völlig OK:

Code [Auswählen] Erweitern

[color=blue]Dim [/color]VarDat3 As Date
[color=blue]Dim [/color]VarDat4 As Date
VarDat3 = "10.10.2011"
VarDat4 = "01.10.2014"...einfach mal ausprobieren. ;-)

[DF6GL]

Hallo,


ich finde diese Zeilen nicht ok, sondern für handwerklichen Murks.

Auch wenn Access-VBA durch mehr oder weniger funktionierenden, von sonstigen Windows-Einstellungen abhängigen internen Datentyp-Konvertierungen in diesen Fall den Literal-String in ein gültiges Datum umsetzen kann.

[ebs17]

Den Hinweis von Franz kann man nur dick unterstreichen.

Wenn in einem englischen Code (VBA ist nun mal so) eine Date-Variable mit einem Text bedient wird, der ein deutsches Datumsformat enthält, ist das grundsätzlich ein Fehler.
Wenn Access/VBA hier zu Fehlertoleranz fähig ist und für sich einen gültigen Wert erzeugt, mag das für einige schön sein, es ist aber auch leichtfertig:
a) Bei solchen Interpretationen in gewissen Konstellationen können durchaus mal Tag und Monat getauscht sein, so dass zwar gültige, aber falsche Datumswerte entstehen.
b) Wie es schon öfter vorgekommen ist: Über eine neue Accessversion oder auch ein Servicepack oder auch schon ein Hotfix kann die vorhandene Fehlertoleranz eingeschränkt oder abgebaut werden.
Die Situation, dass ein immer funktionierender Code "plötzlich und unerwartet" mit Fehler reagiert, ist sehr unangenehm und bei der Fehlersuche anstrengend.
=> "Ruinen können vom Krieg erzählen."

Schwieriger und länger ist die von Franz verwendete korrekte Variante nun auch nicht.
Nebenbei ist dann SQL etwas strikter im Umgang mit Datentypen und verwendeten Formaten.