Hi Christian, es gibt letztendlich nicht *DIE* Lösung, sondern es kommt drauf an, was Dir wichtig ist, bzw. was für Dich funktioniert. Ich will jetzt keinen Exkurs auf Datums-Variationen vornehmen, aber letztlich ist es so:
- Du kannst was DB-spezifisches nehmen (in deinem Fall, bzw. RealDB das DateObject). Das hat den Vorteil, dass es mit der aktuellen DB gut läuft und Du nicht viel nachdenken mußt. - Du kannst Totalseconds nehmen, was ok ist, wenn Du das Datum nicht zu weit in die Vergangenheit, bzw. Zukunft berechnen mußt (weil Du sonst einen Overflow bekommst). Mit Totalseconds kann man gut rechnen, aber wenn das ganze Mal in eine ander DB muß, dann muß halt auch alles kovertiert werden. - Du kannst das Datum als String (nach ISO) speichern, was Dir völlige Flexibilität über alle Datenbanken (und Jahreszahlen) hinweg garantiert. Aber zum Rechnen brauchst Du dann aber separate Funktionen. (Es gibt auch DBs die virtuelle Funktionen unterstützen, da kann man sich so ein Datum dann gleich auch in irgendwas anderes umwandeln lassen. Dann hat man beides... - aber das nur am Rande). Dazwischen gibt es noch jede Menge Möglichkeiten, deshalb ist für dich am Wichtigsten, dass Du Dir klar machst, WAS Du möchtest und OB Du mit Deiner Lösung Dein Ziel bequem erreichst. Ist das der Fall, dann ist Deine Vorgehensweise absolut legitim (Endet aber im Jahre 2040 :-) ) Grüße andy at 21.10.2007 22:03 Uhr, Christian Hahn wrote: > der Rückweg entsprechend: die TotalSeconds aus der DB übergebe ich an ein > Date-Objekt und schreibe das ShortDate in meine Tabelle. > War es etwa so gemeint?
