Access 2007 Runtime: Fehler bei Abfrage auf Datumsfeld

[Klaus-Dieter Gundermann]

Hallo Experten !

Ich bin immer noch dabei meine Application auf Access 2007 umzustellen ...

Meine ersten Tests auf der Arbeitsstation eines Benutzers bringen das folgende
Problem:
Sobald eine Abfrage auf einem Datumswert vergleicht, gibt es die Fehlermeldung:
ODBC: Daten außerhalb des Bereichs. ( Fehlernummer 3238 )

Der SQL-Profiler zeigt mir den Unterschied in der SQL-Abfrage an:

Entwickler-Rechner :
.... WHERE ("dbo"."Angebote"."Datum" >= {d ''2009-08-04''} )

Anwender-Rechner :
.... AND ("dbo"."Angebote"."Datum" >= {ts ''04.08.09''} ) <<<< Falsch

auf beiden Rechner ist installiert:
Windows XP SP3
SQL Native Client sqlncli 2005.90.4035.00
Zugriff auf SQL Server 2005

Unterschied:
Entwickler-Rechner:
- Office 2007 Professional Vollversion 12.0.6425.1000
Anwender-Rechner :
- Office XP Professional Vollversion
- Access 2007 Runtime 12.0.6425.1000

Irgendeine Idee, wieso der ODBC Treiber ( oder Access ? ) den
Datumswert so fehlerhaft angibt ??

Viele Grüße

Klaus

[Karl Donaubauer]

Post by Klaus-Dieter Gundermann
Ich bin immer noch dabei meine Application auf Access 2007
umzustellen ...
Meine ersten Tests auf der Arbeitsstation eines Benutzers bringen
Sobald eine Abfrage auf einem Datumswert vergleicht, gibt es die
Fehlermeldung: ODBC: Daten außerhalb des Bereichs. ( Fehlernummer
3238 )
.... WHERE ("dbo"."Angebote"."Datum" >= {d ''2009-08-04''} )
.... AND ("dbo"."Angebote"."Datum" >= {ts ''04.08.09''} ) <<<< Falsch
Windows XP SP3
SQL Native Client sqlncli 2005.90.4035.00
Zugriff auf SQL Server 2005
- Office 2007 Professional Vollversion 12.0.6425.1000
- Office XP Professional Vollversion
- Access 2007 Runtime 12.0.6425.1000
Irgendeine Idee, wieso der ODBC Treiber ( oder Access ? ) den
Datumswert so fehlerhaft angibt ??

Mit welcher Methode und welchem Format kommt denn der
Datumswert in die Abfrage?

[Klaus-Dieter Gundermann]

So ich habe ein ganz einfaches Formular gemacht, mit Datensatzquelle:
SELECT Angebote.AuftragsNr, Angebote.KundenNr, Angebote.Datum
FROM Angebote
WHERE (((Angebote.Datum)>#8/30/2009#));

auf meinem Entwicklungsrechner funktionierts wunderbar. Der SQL-Profiler zeigt:
SELECT "dbo"."Angebote"."AuftragsNr"
FROM "dbo"."Angebote"
WHERE ("Datum" > {d '2009-08-30'} )

auf dem Anwenderrechner bekomme ich die Fehlermeldung:
ODBC-Aufruf fehlgeschlagen.
[Micorosft][SQL Native Client][SQL Server]Fehler beim Konvertieren einer
Zeichenfolge in einen datetime-Wert.(#241)

Der SQL Profiler zeigt die Abfrage als :
SELECT "dbo"."Angebote"."AuftragsNr"
FROM "dbo"."Angebote"
WHERE ("Datum" > {ts '30.08.09'} )

Nur wieso nimmt der SQL Native Client dieses falsche Format ??

Grüße

Klaus

[Bernd Gilles]

Post by Klaus-Dieter Gundermann
SELECT Angebote.AuftragsNr, Angebote.KundenNr, Angebote.Datum
FROM Angebote
WHERE (((Angebote.Datum)>#8/30/2009#));

Warum castest Du nicht schon in der Abfrage explizit auf den richtigen
Datentyp?
SELECT Angebote.AuftragsNr, Angebote.KundenNr, Angebote.Datum
FROM Angebote
WHERE Angebote.Datum > CAST('30.08.2009' as datetime);

oder auch

SELECT Angebote.AuftragsNr, Angebote.KundenNr, Angebote.Datum
FROM Angebote
WHERE Angebote.Datum > CONVERT(datetime, '30.08.2009');

[Klaus Oberdalhoff]

Hi Bernd,

deine Antwort würde voraussetzen, dass Klaus-Dieter eine PASS-Thru Abfrage
verwendet, aber er arbeitet wahrscheinlich mit gelinken Tabellen und müsste
wohl die gesamte Appli umschreiben, wenn er auf Pass-Through umstellt. Und
in "pur Access" ist das so geschriebene Datum die Eingabe, die der
Query-Parser erzeugt, egal wie du das Datum direkt eingibst ...

mfg

Klaus

[Bernd Gilles]

Hi Klaus,

Post by Klaus Oberdalhoff
deine Antwort würde voraussetzen, dass Klaus-Dieter eine PASS-Thru
Abfrage verwendet, aber er arbeitet wahrscheinlich mit gelinken Tabellen
und müsste wohl die gesamte Appli umschreiben, wenn er auf Pass-Through
umstellt. Und in "pur Access" ist das so geschriebene Datum die Eingabe,
die der Query-Parser erzeugt, egal wie du das Datum direkt eingibst ...

berechtigter Einwand.

Interessant wäre, was der Parser z.B. aus

SELECT Angebote.AuftragsNr, Angebote.KundenNr, Angebote.Datum
FROM Angebote
WHERE Angebote.Datum > CDate('30.08.2009');

machen würde.
Ich befürchte allerdings, dass auch das nicht wirklich 'ne Veränderung
bringt.
Ich werde mal versuchen das zu testen.

[Bernd Gilles]

Post by Klaus-Dieter Gundermann
SELECT Angebote.AuftragsNr, Angebote.KundenNr, Angebote.Datum
FROM Angebote
WHERE Angebote.Datum > CDate('30.08.2009');
Ich werde mal versuchen das zu testen.

*Ergebnis:*
im Gegensatz zu '... >= #8/30/2009#'

führt ein '... >= CDate("30.08.2009")'
im Profiler zu folgendem:
exec sp_executesql N'SELECT "dbo"."Angebote"."AuftragsNr" FROM
"dbo"."Angebote" WHERE ("Datum" >= @P1 ) ',N'@P1 datetime','2009-01-01
00:00:00'

Es wird also ein mit Parametern besetztes SQL-Statement per
sp_executesql ausgeführt - und die Parameter sehen auch noch richtig aus :-)

Wäre 'nen Versuch Wert.

BTW: Ich würde das Feld nicht unbedingt "Datum" nennen - könnte zu
unerwünschten Seiteneffekten führen.

[Peter Doering]

Hallo,

Post by Bernd Gilles

Post by Klaus-Dieter Gundermann
SELECT Angebote.AuftragsNr, Angebote.KundenNr, Angebote.Datum
FROM Angebote
WHERE Angebote.Datum > CDate('30.08.2009');
Ich werde mal versuchen das zu testen.

*Ergebnis:*
im Gegensatz zu '... >= #8/30/2009#'
führt ein '... >= CDate("30.08.2009")'
exec sp_executesql N'SELECT "dbo"."Angebote"."AuftragsNr" FROM
00:00:00'
Es wird also ein mit Parametern besetztes SQL-Statement per
sp_executesql ausgeführt - und die Parameter sehen auch noch richtig aus :-)

Von der Syntax schon, vom Wert her nicht wirklich, wenn aus dem 30.08.09
der 01.01.09 wird ;-)

Abgesehen davon, dass das Problem durch den /decompile behoben worden ist,
wuerde ich generell von Funktionen wie CDate oder DateValue Abstand nehmen,
weil dabei die Regionaleinstellungen schnell mal einen Strich durch die
Rechnung machen koennen. CDate('30.08.2009') ist immer klar, also jedes
Datum ab dem 13. des Monats, aber davor besteht die Verwechslungsgefahr
zwischen Monat/Tag: CDate('12/09/2009') = 9. Dez oder 12. Sep? ;-)

Gruss - Peter

[Bernd Gilles]

Post by Peter Doering
Von der Syntax schon, vom Wert her nicht wirklich, wenn aus dem 30.08.09
der 01.01.09 wird ;-)

upps, da hab' ich doch glatt in meinem manuell angepassten Text noch was
vergessen, denn ich hab' natürlich meine vorhandenen Daten im SQL-Server
verwendet und die Feld- und Tabellennamen nachträglich an Klaus-Dieter's
Gegebenheiten angepasst.
;-)

Post by Peter Doering
Abgesehen davon, dass das Problem durch den /decompile behoben worden ist,
wuerde ich generell von Funktionen wie CDate oder DateValue Abstand nehmen,
weil dabei die Regionaleinstellungen schnell mal einen Strich durch die
Rechnung machen koennen. CDate('30.08.2009') ist immer klar, also jedes
Datum ab dem 13. des Monats, aber davor besteht die Verwechslungsgefahr
zwischen Monat/Tag: CDate('12/09/2009') = 9. Dez oder 12. Sep? ;-)

Ist natürlich auch richtig.
Ich habe bisher meist mit deutschen Ländereinstellungen gearbeitet, hab'
also kaum Erfahrung mit anderen Formaten.

AFAIK sollte CDate("2009-08-31") aber immer funktionieren.

[Peter Doering]

Hallo,

Post by Bernd Gilles

Post by Peter Doering
Abgesehen davon, dass das Problem durch den /decompile behoben worden ist,
wuerde ich generell von Funktionen wie CDate oder DateValue Abstand nehmen,
weil dabei die Regionaleinstellungen schnell mal einen Strich durch die
Rechnung machen koennen. CDate('30.08.2009') ist immer klar, also jedes
Datum ab dem 13. des Monats, aber davor besteht die Verwechslungsgefahr
zwischen Monat/Tag: CDate('12/09/2009') = 9. Dez oder 12. Sep? ;-)

Ist natürlich auch richtig.
Ich habe bisher meist mit deutschen Ländereinstellungen gearbeitet, hab'
also kaum Erfahrung mit anderen Formaten.
AFAIK sollte CDate("2009-08-31") aber immer funktionieren.

Als Literal uebergeben hast du sowieso immer die Hoheit ueber den Wert ;-)

Aber wenn ein String auf User-Eingabe zurueckgeht und diese nicht in dt.
Umgebung geschieht, sieht das anders aus. Gefaehrlich sind in erster Linie
die Formate D/M/Y bzw. M/D/Y aus den beschriebenen Gruenden. Darueber
hinaus /kann/ es zu Fehlern kommen, wenn das Jahr 2-stellig eingegeben
wird, auch wieder, solange wir 2013 nicht erreicht haben. Aber in dt.
Umgebung bist du auch davor relativ sicher.

Gruss - Peter

[Bernd Gilles]

Hi Peter,

Post by Peter Doering
Aber wenn ein String auf User-Eingabe zurueckgeht und diese nicht in dt.
Umgebung geschieht, sieht das anders aus. Gefaehrlich sind in erster Linie
die Formate D/M/Y bzw. M/D/Y aus den beschriebenen Gruenden. Darueber
hinaus /kann/ es zu Fehlern kommen, wenn das Jahr 2-stellig eingegeben
wird, auch wieder, solange wir 2013 nicht erreicht haben.

Da könnte man dann noch mit Eingabemasken, DateTimePicker, IsDate() und
Format() eingreifen und eine Benutzereingabe in das richtige Format
prügeln ;-)

[Peter Doering]

Hallo Bernd,

Post by Bernd Gilles

Post by Peter Doering
Aber wenn ein String auf User-Eingabe zurueckgeht und diese nicht in dt.
Umgebung geschieht, sieht das anders aus. Gefaehrlich sind in erster Linie
die Formate D/M/Y bzw. M/D/Y aus den beschriebenen Gruenden. Darueber
hinaus /kann/ es zu Fehlern kommen, wenn das Jahr 2-stellig eingegeben
wird, auch wieder, solange wir 2013 nicht erreicht haben.

Da könnte man dann noch mit Eingabemasken, DateTimePicker, IsDate() und
Format() eingreifen und eine Benutzereingabe in das richtige Format
prügeln ;-)

Eingabemasken bei DateTime-Feldern sind "boese", weil sie nur bei
identischer Regionaleinstellung Sinn machen. In dem Fall hast du das
beschriebene Problem aber auch garnicht. Zwing mal einen Ami, das Datum im
Format DD.MM.YYYY einzugeben. Der wird dir was erzaehlen ;-)

IsDate() faellt auf die gleichen Probleme herein wie DaveValue und CDate,
scheidet also aus.

DateTimePicker waere die ideale Loesung. Also, alles nach A07 konvertieren
... ;-)

Gruss - Peter

[Klaus-Dieter Gundermann]

Sehr interessant...

ein DCR (Decompile, Compact, Repair) hat geholfen...

( Was immer sich Access da für komische Sachen gemerkt hat ...)

Thx

Klaus

PS: Ja, es sind gelinkte Tabellen