Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Problem mit DateTime in AccessDB (https://www.delphipraxis.net/105714-problem-mit-datetime-accessdb.html)

mischerr 28. Dez 2007 00:03

Datenbank: Access • Version: 2000 • Zugriff über: ADO / JET4 / Access2000

Problem mit DateTime in AccessDB
 
Ich arbeite ohne Access, direkt aus Delphi2007 mit einer MDB Datei.
Die Tabellen wurden über Delphi per SQL angelegt:

SQL-Code:
CREATE TABLE Transactions
(Id COUNTER NOT NULL PRIMARY KEY,
 ...
 DateAndTime DATETIME NOT NULL DEFAULT NOW(),
 ...
)

CREATE INDEX Idx_Transactions_DAT
ON Transactions
(DateAndTime)
Ok, ich weiss mittlerweile schon selbst das "Date" in einer AccessDB ein böses Wort ist, dass man wohl vermeiden sollte und in diversen SQL-Konstrukten in "" setzen muss. Aber, passiert ist nunmal passiert... :-(

Mein Problem ist: Egal was ich mache und wie ich Abfrage, die Auswertung von "DateAndTime" liefert einfach falsche Ergebnisse.
Dabei spielt es keine Rolle, ob ich das DateTime-Feld als String formatiere und per SQL.Text übergebe, oder per typisiertem ADO-Parameter.

Selbst wenn ich in Access 2000 eine Abfrage erstellen und im SQL-Editor einen DateTime-Wert eingebe, erhalte ich falsche Ergebnisse.


Hat dazu jemand eine Idee? Kennt jemand das Phenomen?

mkinzler 28. Dez 2007 05:36

Re: Problem mit DateTime in AccessDB
 
Was bedeutet falsch?

alzaimar 28. Dez 2007 08:59

Re: Problem mit DateTime in AccessDB
 
Ich meine mich zu erinnern, das man in Access das Datum in '#' einfässt, und nicht in Hochkommata, versuchs mal mit
SQL-Code:
select * from foobar where DateTimeField = #2007-12-01#

mikhal 28. Dez 2007 09:47

Re: Problem mit DateTime in AccessDB
 
Format stimmt aber nicht ganz. Access erwartet die amerikanische Notation: #mm/dd/yyyy#

Grüße
Mikhal

mischerr 28. Dez 2007 15:24

Re: Problem mit DateTime in AccessDB
 
Danke, die Einklammerung in ## funktioniert solange es nur ein Datum ist (im Moment ausreichend).
Handelt es sich jedoch um einen Abfrageparameter mit Zeitanteil funktioniert #12/28/2007 01:30:56# zwar in Access, aber Delphi beschwert sich über den ":". Egal ob ParamCheck an oder aus ist. Wird das ganze in Quotes gefasst, schlägt auch dies fehl und ich bekomme eine AV wg unverträglichem Datentyp.

BTW1: Funktioniert die ##-Notation nur für Access, oder ist sie auch zum MS SQL Express kompatibel?

BTW2: @mkinzler: Funktioniert soll bedeuten, dass Ergebnisse geliefert wurden bzw. nicht geliefert wurden, die im selektierten Bereich liegen und daher erscheinen müssten.

grenzgaenger 28. Dez 2007 22:13

Re: Problem mit DateTime in AccessDB
 
mein vorschlag lautet, vergiss datetime, also die ganze einklammerung mit #yyyy-mm-dd hh:mm:ss#, sondern wandele das datum einfach in 'n float um und schreib das so in die datenbank weg... beim einlesen einfach wieder das das datum in 'n datetime konvertieren und du bist fein raus..

abfragen gehen dann wie folgt
SQL-Code:
select * from tabelle where zeitdatum = 49494.292
oder so in der art <HTH>

hoika 29. Dez 2007 06:37

Re: Problem mit DateTime in AccessDB
 
Hallo,

benutze doch Parameter und AsDateTime


Heiko
PS: und ne ordentliche DB ;)

Bernhard Geyer 29. Dez 2007 07:23

Re: Problem mit DateTime in AccessDB
 
Zitat:

Zitat von mischerr
BTW1: Funktioniert die ##-Notation nur für Access, oder ist sie auch zum MS SQL Express kompatibel?

Access hat teilweise SQL-Eigenheiten die man bei keiner andern DB findet. ##-Notation ist so was.
Aber wie schon angemerkt: Benutz parametrisierte Abfragen.

grenzgaenger 3. Jan 2008 19:19

Re: Problem mit DateTime in AccessDB
 
Zitat:

Zitat von mikhal
Format stimmt aber nicht ganz. Access erwartet die amerikanische Notation: #mm/dd/yyyy#

Grüße
Mikhal

beides ist möglich, ISO und US Format. Wobei ich immer dem ISO Format den Vorzug gebe.


Alle Zeitangaben in WEZ +1. Es ist jetzt 03:45 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz