[Gelöst] SQLite: Darstellung Datum anders als Speicherung in Datenbank

[Ich934]

Hallo,

ich möchte die Darstellung von Datumswerten im Programm (und auch die Eingabe) anders gestalten als diese in der DB gespeichert sind. Vielleicht hat hier jemand eine Idee.

Gegeben:
Daten sind abgelegt in einer SQLite-Datenbank und Datumswerte werden als Textfeld abgespeichert. Speicherformat ist YYYY-MM-DD. Hierbei kann es vorkommen, dass nur teilweise gefüllte Datumsfelder vorhanden sind. Gefüllt wird mit einem Leerzeichen und Bindestrich sind immer da (Möglichkeiten: 2021-11-21; 2121-11- ; 2121- -21; 2121- - ; -11-21; usw.).
Die Datumsfelder werden im Programm sowohl in TDBEdit als auch in TDBGrid-Komponenten verwendet. Diese sind ja direkt auf das Feld gemappt und es erzeugt eine direkte Anzeige des Inhaltes aus der Datenbank.
Rahmenparameter:
Lazarus: 2.0.12
FPC: 3.2.2
DB-Zugriff: LiteDAC

Gewünschter Soll-Zustand:
Die Darstellung und Eingabe im Programm soll im Format DD.MM.YYYY erfolgen und die entsprechende Konvertierung im HIntergrund erfolgen. Entsprechende fehlende Elemente sollen berücksichtigt werden.

Ideen von mir:
Beim DB-Grid kann ich hier natürlich die Ausgabe überarbeiten und einen entsprechenden Editor schreiben. Das wäre also unproblematisch. Aber was mache ich bei den TBEdit-Feldern? Zusätzliche Textfelder die die Konvertierung dann übernehmen? Gibt es hier eine bessere Lösung?

Vielen Dank.
cu tb

[Sieben]

Schau dir mal TField.OnGetText und OnSetText an. Für eine Anzeige im Grid verwende ich zB:

Code: Alles auswählen

procedure TdmMain.qHauptDatumGetText(Sender: TField; var aText: string; DisplayText: Boolean);
begin
  if DisplayText and not Sender.IsNull then
  begin
    aText := Sender.AsString;
    aText := DateToStr(StrToDate(aText,cISODate,cISODate[8]));
  end;
end; 

cISODate ist das ISO-Datumsformat 'YYYY-MM-DD'. Zu beachten ist, dass aText nicht vorbelegt ist, du musst dir die gewünschte Grundlage also erstmal selbst beschaffen, hier mit Sender.AsString, Und mit deinen 'Leerstellen' müsstest du natürlich etwas mehr Aufwand betreiben.

Im übrigen habe ich hier auch gerade eine Erweiterung des TDBDateTimePicker vorgestellt, die unabhängig von der jeweiligen Darstellung ISO-Strings in die Datenbank schreibt.

[Winni]

Hi!

Wo kommt cISOdate her?

Finde ich weder in Lazarus noch in fpc.

Winni

[Ich934]

Moin,

vielen Dank. Das schau ich mir mal an. Die Konvertierungsfunktionen liegen ja schon vor. Das wäre also nicht das Problem. Aber OnGetText und OnSetText kannte ich noch nicht. Hätte ich selber drauf kommen können.

Wegen deinem TDBDateTimePicker: welchen Zeitraum kannst du abdecken? Auch zurück bis 4000 v.Chr.?

[Sieben]

Äh, nein. Da greifen die internen Beschränkungen von TDBDateTimePicker, die im Sourcecode desselben erläutert sind (und der auch nicht 'meiner' ist). Es wäre aber wohl möglich, sich eine Version zu stricken, die das umgeht. Wie rechnet ihr diese Werte denn intern, auch mit TDateTime?

[Winni]

Hi!

Systutlls TDateTime startet am 30. Dezember 1899 0:00 Uhr.
Sollte wohl der 1.1.1900 werden .....

Wenn Du mit historischen Daten rechnen willst, brauchst Du eine Bibliothek für das Julianische Datum.

Das fängt am 1. Januar 4713 vor Null um 12:00 mittags an. Enthält auch das Jahr Null und man kann wunderbar damit rechnen. Wird von Archäologen und Historikern genutzt. Nur die Umrechnung in den gregorianischen Kalender ist etwas lästig. Aber das hat Gauß bereits für uns erledigt.

Winni

[Ich934]

Das fängt am 1. Januar 4713 vor Null um 12:00 mittags an. Enthält auch das Jahr Null und man kann wunderbar damit rechnen. Wird von Archäologen und Historikern genutzt. Nur die Umrechnung in den gregorianischen Kalender ist etwas lästig. Aber das hat Gauß bereits für uns erledigt.

Der Kandidat hat 100 Punkte.

Ja, gibt mehrere Probleme. Bei den Historikern und den Archäologen gibt es kein Jahr 0 (das ist kein großes Problem und lässt sich immer leicht beheben). Schwieriges ist es eher, dass es keine festen Umstellungstermin gibt ist das dann immer in Bezug auf ein konkretes Datum echt nervig.

[Winni]

Hi!

Meinst Du Umstellung auf gregorianischen Kalender???

Ja - das ist unübersichtlich und teilweise lustig.

Ein einziges Mal macht die katholische Kirche etwas richtig. Nämlich den gregorianischen Kalender im Oktober 1582 einzuführen. Die meisten katholischen Länder folgten sofort oder recht bald.

Den Evangelen war das natürlich suspekt. Und den Orthodoxen erst recht. Es dauerte bis 1700-und bis der auch bei den Evangelen eingeführt wurde - in jedem Land anders. In Schweden erst am 1.1.1800.

Das ist aber nix gegen die Orthodoxen. In Russland musste erst die Oktober-Revolution und Lenin kommen, bis die auch das gleiche Datum hatten, wie der Rest Europas. Weshalb die Oktober-Revolution eigentlich eine November-Revolution ist.

Noch sturer ist die griechisch-orthodoxe Kirche. Die haben ihn noch immer noch nicht eingeführt.

Wikipedia hat bei Menschen und Ereignissen aus diesem Zeitraum die angenehme Angewohnheit beide Daten anzuigeben.

Großes Wirrwarr. Da helfen nur Länder-Tabellen. Die natürlich bei den unzähligen Mini-Fürstentümern damals in D recht lang sind.

Fast so ein Chaos, wie die Sommer-Zeit im 2. Weltkrieg ......

Winni

[Ich934]

Richtig. Hast du hier eine Länder-Tabelle, die auch maschinenlesbar ist? Ich kenn zwar hier für meine Umgebung die entsprechenden Werte, die ist aber halt nicht allgemeinverbindlich.

So back-to-topic... OnGetText und OnSetText gibt es jedoch nicht bei einem DBGrid. Das heißt das kann ich hier nicht verwenden und ich werde das doch wirklich mit einem Editor und beim Darstellen realisieren müssen. Für ein DBEdit hab ich noch keine Lösung ausser meiner genannten.

[Winni]

Richtig. Hast du hier eine Länder-Tabelle, die auch maschinenlesbar ist? Ich kenn zwar hier für meine Umgebung die entsprechenden Werte, die ist aber halt nicht allgemeinverbindlich.

Hi!

Maschinenlesbares habe ich nicht.

Relativ ausführlich ist dies:
http://genwiki.genealogy.net/Gregorianischer_Kalender

Winni

[Sieben]

OnGetText und OnSetText gibt es jedoch nicht bei einem DBGrid.

Nö. Aber bei dem TField, das an's DBGrid angebunden wird. Hast du die Felder deiner DataSets in der IDE definiert oder überlässt du das der impliziten Erzeugung zur Laufzeit? Wenn du die Darstellung wirklich kontrollieren willst, solltest du sie in der IDE anlegen, wie übrigens auch die Columns deines DBGrid.

[PascalDragon]

Systutlls TDateTime startet am 30. Dezember 1899 0:00 Uhr.
Sollte wohl der 1.1.1900 werden .....

TDateTime ist kompatibel zu OLE DateTime, welches seinen Ursprung in Visual Basic und Excel hat, welches wiederum darauf basiert, dass Lotus 123 das Jahr 1900 als Schaltjahr behandelt hat, um ein paar Byte an Code zu sparen. Siehe hier.

[Winni]

TDateTime ist kompatibel zu OLE DateTime, welches seinen Ursprung in Visual Basic und Excel hat, welches wiederum darauf basiert, dass Lotus 123 das Jahr 1900 als Schaltjahr behandelt hat, um ein paar Byte an Code zu sparen. Siehe hier.

Hi!

Den Witz kannte ich noch nicht!

Thanx
Winni

[Ich934]

OnGetText und OnSetText gibt es jedoch nicht bei einem DBGrid.

Nö. Aber bei dem TField, das an's DBGrid angebunden wird. Hast du die Felder deiner DataSets in der IDE definiert oder überlässt du das der impliziten Erzeugung zur Laufzeit? Wenn du die Darstellung wirklich kontrollieren willst, solltest du sie in der IDE anlegen, wie übrigens auch die Columns deines DBGrid.

Ha, das ist die Lösung! Prima! Funktioniert einwandfrei. Vielen Dank.

Die Felder sind über die IDE definiert und hängen an Tabellen (TLiteTable) oder Queries (TLiteQuery). Wieder etwas gelernt.

[Ich934]

Richtig. Hast du hier eine Länder-Tabelle, die auch maschinenlesbar ist? Ich kenn zwar hier für meine Umgebung die entsprechenden Werte, die ist aber halt nicht allgemeinverbindlich.

Hi!

Maschinenlesbares habe ich nicht.

Relativ ausführlich ist dies:
http://genwiki.genealogy.net/Gregorianischer_Kalender

Winni

Ja, das kenn ich auch. OK, dann muss ich daraus mir selber etwas basteln. Trotzdem vielen Dank!