DateTime Format speichern

[Privateer3000]

Hallöchen,

mal eine grundsätzliche Frage.
Welche Datetime format eignet sich am besten
es in einer DB abzuspeichern? Und zwar
um später einen integeren Vergleichswert
zur Hand zu haben mit dem man arbeiten kann.
ZB frühestes Datum, letztes Datum usw.

Grüße

[holliesoft]

Hi,

ich selbst benutze der Einfachheit halber einen Integer-Wert. Damit lässt sich am besten Arbeiten.

Gruß
Patrick

[mkinzler]

TDateTime ist ein Double-Typ

[holliesoft]

Hi,

ich ging davon aus, dass der Fragesteller "Datum" im Sinne von http://de.wikipedia.org/wiki/Kalenderdatum meint("Benennung eines Tages im jeweiligen Kalenderjahr im Rahmen eines Kalenders"), da das Wort "Datum" benutzt wurde. Für Datums- und Zeitwerte ist natürlich der Typ double korrekt.

Gruß,
Patrick

//Edit
<Klugscheiss>
ein Datums-Zeit-Wert im Unix Format ist natürlich ein Integer ;-)
</Klugscheiss>

[mkinzler]

Access wird natürlich das Format der Konkurrenz verwenden :mrgreen:

[Sherlock]

Alle mir bekannten Datenbanken stellen DateTime als eigenen Datentyp zur Verfügung.

Da muss man in der Regel nicht drüber nachdenken.

Sherlock

[holliesoft]

Zitat:

Zitat von Sherlock

Alle mir bekannten Datenbanken stellen DateTime als eigenen Datentyp zur Verfügung.

Da muss man in der Regel nicht drüber nachdenken.

Sherlock

Hab mit verschiedenen Datenbanken wenig Erfahrung, nutze nur MySQL und SQLite, ist denn der DateTime-Typ bei den verschiedenen Datenbanken auf die selbe Art und Weise implementiert?

Gruß
Patrick

[Sherlock]

Das ist ja nicht die Frage gewesen glaub ich...oder möchte der OP zwischen verschiedenen DBs vergleichen? Wobei selbst dann eigentlich kein Problem bestehen sollte, wenn er die verschiedenen DateTimes erst nach Delphi holt und dort erst vergleicht.

Edit: Im übrigen ist ein Integer als DateTime nicht Jahr 2038 fest. ;)
http://de.wikipedia.org/wiki/Jahr-2038-Problem

Sherlock

[shmia]

MS Access speichert ein DateTime Wert intern genau in der gleichen Weise, wie Delphi auch:
Anzahl der Tage seit 31.12.1899 als 64 Bit Fliesskommazahl.
Dies ist ebenfalls identisch mit dem Datums/Zeit-Format, dass MS für COM/DCOM/ActiveX definiert hat und dass Borland dann übernommen hat.
Daher ist Access wirklich sehr unproblematisch in Bezug auf Datums/Zeit-Werte.
Man kann das Datum sogar als Flieskommazahl ansprechen:

Delphi-Quellcode:

Query.SQL.Text := 'UPDATE Tabelle SET Datumsfeld='+FloatToStr(Now());
Query.Execute;

[mkinzler]

Am wenigsten Probleme hat man aber durch Parametrisierung der Abfragen.

[Privateer3000]

Vielen Dank Leute,
huch so eine Diskussion....
hatte ich nun nicht erwartet
Das Problem wie ich darauf gestoßen bin
war mit min(datum) eine SQl-abfrage zu starten.
Jedoch brichte der compiler mit einer Jet-Fehlermeldung
ab. Ziel war es das älteste Datum in einen Datetimepicker
zu setzen.
Gespeichert habe ich bisher mit DateTimeToStr was ja
auch klappte.

Geht das nun nicht mit MIN(*) das älteste herauszufinden?

[mkinzler]

Und mit welchem Typ in der Datenbank?

[Sherlock]

Jet...das hört sich nach Access an.

Schau doch mal was für Datentypen Deine DB zur Verfügung stellt und nutz die dann. Ein Datum als String ist nicht wirklich optimal.

Sherlock

[TeronG]

Zitat:

Zitat von Privateer3000

Geht das nun nicht mit MIN(*) das älteste herauszufinden?

Naja keine Ahnung, ob Min() bei Strings/Texten geht aber bei DateTime/Double gehts bestimmt.

[Privateer3000]

Siehe Eröffnungsthema: MDB
ja mit Access.
Der Feldtyp ist Datum/Zeit.

so soll die abfrage aussehen:

Delphi-Quellcode:

timequer.Close;
timequer.SQL.Text:='SELECT MAX(dastring) as mindat';
timequer.SQL.Add(' FROM dauerspeicher');
timequer.Open;
timevon.MinDate:=StrToDateTime(timequer.fieldbyname('mindat').AsString);

[grenzgaenger]

Zitat:

Zitat von Privateer3000

Vielen Dank Leute,
huch so eine Diskussion....
hatte ich nun nicht erwartet
Das Problem wie ich darauf gestoßen bin
war mit min(datum) eine SQl-abfrage zu starten.
Jedoch brichte der compiler mit einer Jet-Fehlermeldung
ab. Ziel war es das älteste Datum in einen Datetimepicker
zu setzen.
Gespeichert habe ich bisher mit DateTimeToStr was ja
auch klappte.

Geht das nun nicht mit MIN(*) das älteste herauszufinden?

tja, da wirst wohl 'n full table scan machen müssen... wenn du nicht zufälligerweise ins ISO format umgewandelt hast... :angel2:

[angos]

@grenzgaenger:

du hast nicht zuende gelesen :mrgreen:
ich denke das mit dem StrToDateTime bezieht sich nur auf den Sql an sich, denn:

Zitat:

Zitat von Privateer3000

Siehe Eröffnungsthema: MDB
ja mit Access.
Der Feldtyp ist Datum/Zeit.

so soll die abfrage aussehen:

Delphi-Quellcode:

timequer.Close;
timequer.SQL.Text:='SELECT MAX(dastring) as mindat';
timequer.SQL.Add(' FROM dauerspeicher');
timequer.Open;
timevon.MinDate:=StrToDateTime(timequer.fieldbyname('mindat').AsString);

oder ist access so doof, dass dort Datum/zeit eigentlich ein String ist? (habe selber noch nicht mit Access gearbeitet, aber das wäre ja mal wirklich mehr als dämlich ;)

Also: Normalerweise sollte das so gehen, was mir auffällt ist, dass du MAX(dastring) ausließt, aber in MinDate schreibst. Nicht, dass dein Fauxpas da liegt :)

[Privateer3000]

Zitat:

Zitat von angos

Also: Normalerweise sollte das so gehen, was mir auffällt ist, dass du MAX(dastring) ausließt, aber in MinDate schreibst. Nicht, dass dein Fauxpas da liegt :)

Nein, durch herumprobieren ist nur die zuordnung durcheinander.
aber an der funktion sollte sich ja nichts ändern.
In der entsprechenden Zelle der Tabelle liegt auch ganz normal der Inhalt:
08.05.2008 12:58:47.
Oder ist beim speichern die Umwandlung DateTimeToStr nicht erforderlich
wenn der Typ ohnehin Datum/Zeit ist?

[mkinzler]

Komt darauf an, ob du eine Abfragestring erzeugt oder mit Parametern arbeitest.

[Privateer3000]

leider versteh ich die Frage nicht,
ich hab doch oben den quell gepostet...
oder meinst du was anderes?

[mkinzler]

War keine Frage sondern ein Antwort:
Bei

Delphi-Quellcode:

Query.SQL.Text := 'UPDATE Tabelle SET Datumsfeld='+FloatToStr(Picker.Date);

muss es natürlich sein, aber bei

Delphi-Quellcode:

Query.SQL.Text := 'UPDATE Tabelle SET Datumsfeld=:datum';
Query.SQL.ParamByName('datum').Value := Picker.Date;

nicht.

[Privateer3000]

soweit so gut,
aber warum geht mein Beispiel nicht?

Delphi-Quellcode:

timequer.Close; 
timequer.SQL.Text:='SELECT MAX(dastring) as mindat'; 
timequer.SQL.Add(' FROM dauerspeicher'); 
timequer.Open; 
timevon.MinDate:=StrToDateTime(timequer.fieldbyname('mindat').AsString);

[Sherlock]

Zitat:

Zitat von Privateer3000

soweit so gut,
aber warum geht mein Beispiel nicht?

Delphi-Quellcode:

timequer.SQL.Text:='SELECT MAX(dastring) as mindat';

Bringst Du eventuell max und min durcheinander, oder bekommst du eine richtige Fehlermeldung?

Sherlock

[Privateer3000]

mit dem min und max hat glaub ich nichts zu tun
dastring ist das Feld vom typ Datum/Zeit
und mindat einfach nur ne variable

[angos]

hmm,

sag doch nochmal bitte, was ganz genau das Problem ist.

Gibt er einen falschen Wert zurück?`wenn ja, welchen wert gibt er zurück und was sollte er deiner meinung nach zurückgeben.

Bekommst du eine Fehlermeldung? Wenn ja, bitte die genaue Fehlermeldung hier posten oder als screenshot rein


Gruß
angos

[Privateer3000]

anbei die Fehlermeldung,
an der Zuweisung an den
DateTimePicker (timevon.MinDate)
kann es nicht liegen.#Ich geh davon aus
das die SQL-anweisung fehler erzeugt.
Aber warum?

[shmia]

Stelle erst mal sicher, dass du eine funktionierende MDAC und Jet-Engine Installation auf deinem Rechner hast.
Das bedeutet: MDAC Version 2.8 und Jet-Engine Servicepack 8 (SP7 geht auch) installieren.
http://www.microsoft.com/downloads/d...0-3a1afbd5922e
http://www.microsoft.com/downloads/r...DisplayLang=en

[Privateer3000]

Danke shmia
es sind soviele andere zugriffe
in dem Projekt, alle funktionieren.
Es kann unmöglich daran liegen.

[shmia]

Zitat:

Zitat von Privateer3000

Es kann unmöglich daran liegen.

Du hast gerade das Wort "unmöglich" ausgesprochen.
Diese Wort ist in Zusammenhang mit Fehlersuche in Software verboten. :zwinker:
Die Zugriffsverletzung tritt innerhalb der DLL "msjet40.dll" auf und die gehört zur Jet-Engine.
Deine SQL-Abfrage sieht soweit OK aus.
Systematisches Ausschliesen von Fehlerquellen ist jetzt angesagt!
Wenn du auf einem Hausdach stehst und die Balken passen nicht zusammen, dann sollte man zuerst mal schauen, ob die Wände überhaupt gerade sind.

[Privateer3000]

ja sicher hast du recht,
aber ich schliesse es so gut wie aus
da alle anderen querys,datasets und source
funktionieren. warum ausgerechnet das eine nicht?
Ich hab es zumindest genau untersucht ob ein
falsche Parameter im OI vorliegen.
Auch ob reservierte Wörter vorliegen...nichts.
Auch habe ich statt der o.g. Abfrage eine
innocente Standardabfrage gestartet (select * from dauerspreicher)
funkioniert tadellos. Nur mit Aggregat -> Pustekuchen.

[Sherlock]

Du hast selbstverständlich diese Abfrage auch direkt in Access mal ausprobiert und keinen Fehler bekommen, richtig?

Sherlock

[Privateer3000]

Mal so gesprochen,
ich habe keine Ahnung wie ich in Access eine SQL-Abfrage generiere
:oops:

[Privateer3000]

Zitat:

Zitat von Privateer3000

Mal so gesprochen,
ich habe keine Ahnung wie ich in Access eine SQL-Abfrage generiere
:oops:

Ausser einen Bericht su erstellen,
der aber funktioniert.

[Sherlock]

Schau mal ins Bildchen...das müsste helfen um die Abfragen zu finden. Auch in einem neueren Access hat sich nicht sooo viel geändert.

Sherlock

[shmia]

Zitat:

Zitat von Privateer3000

aber ich schliesse es so gut wie aus
da alle anderen querys,datasets und source
funktionieren. warum ausgerechnet das eine nicht?

Schon wieder dieser Denkfehler!
Wenn eine Software (hier: Jet-Engine) doch einen Bug hat, dann wird sich dieser Bug doch nur unter ganz bestimmten Unständen zeigen.

Ich habe bei älteren Versionen der Jet-Engine 4 schon den Fall gehabt, dass eine gültige Abfrage nicht funktioniert.
Wenn man dann die Reihenfolge der Joins umstellt, dann gab es keinen Fehler mehr.
Es ist auch ein Unterschied, ob die Abfrage aus MS Access oder über ADO auf die Jet-Engine losgelassen wird.
Solange du nicht sicher weisst, ob auf deinem Rechner die Jet-Engine SP 8 und MDAC 2.8 SP1 installiert ist,
weisst du auch nicht wie "verbugt" deine Jet-Engine ist.
Ich kann dir nur aus langjähriger Erfahrung mit der Jet-Engine sagen, dass ältere Versionen der Jet-Engine deutlich mehr Bugs (> 30 Stück) haben als obige Kombination.

[Privateer3000]

Gut, von solchen BUgs gehe ich nicht aus
*schon wieder ein Fehler*
ich hab jetzt mehrere Tests gemacht und festgestellt
dass außer dieser einen Abfrage alle funktionieren.
Ziemlich merkwürdig, aber gut ich update erstmal.

Vielen Dank an alle
und ein schönes Wochenende