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

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
Ich934
Lazarusforum e. V.
Beiträge: 264
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

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

Beitrag von 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
Zuletzt geändert von Ich934 am Di 23. Nov 2021, 19:10, insgesamt 1-mal geändert.
Tipp für PostgreSQL: www.pg-forum.de

Sieben
Beiträge: 127
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.0.10, FPC 3.2.0
CPU-Target: i386

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von 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.

Benutzeravatar
Winni
Beiträge: 990
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.0.12, fpc 3.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von Winni »

Hi!

Wo kommt cISOdate her?

Finde ich weder in Lazarus noch in fpc.

Winni

Ich934
Lazarusforum e. V.
Beiträge: 264
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von 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. :roll:

Wegen deinem TDBDateTimePicker: welchen Zeitraum kannst du abdecken? Auch zurück bis 4000 v.Chr.?
Tipp für PostgreSQL: www.pg-forum.de

Sieben
Beiträge: 127
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.0.10, FPC 3.2.0
CPU-Target: i386

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von 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?

Benutzeravatar
Winni
Beiträge: 990
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.0.12, fpc 3.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von 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
Lazarusforum e. V.
Beiträge: 264
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von Ich934 »

Winni hat geschrieben:
Mo 22. Nov 2021, 14:22
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.
Tipp für PostgreSQL: www.pg-forum.de

Benutzeravatar
Winni
Beiträge: 990
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.0.12, fpc 3.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von 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
Lazarusforum e. V.
Beiträge: 264
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von 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.
Tipp für PostgreSQL: www.pg-forum.de

Benutzeravatar
Winni
Beiträge: 990
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.0.12, fpc 3.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von Winni »

Ich934 hat geschrieben:
Di 23. Nov 2021, 09:30
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
Beiträge: 127
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.0.10, FPC 3.2.0
CPU-Target: i386

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von 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
Beiträge: 397
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von PascalDragon »

Winni hat geschrieben:
Mo 22. Nov 2021, 14:22
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.
FPC Compiler Entwickler

Benutzeravatar
Winni
Beiträge: 990
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.0.12, fpc 3.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von Winni »

PascalDragon hat geschrieben:
Di 23. Nov 2021, 14:00


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
Lazarusforum e. V.
Beiträge: 264
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von Ich934 »

Sieben hat geschrieben:
Di 23. Nov 2021, 12:36
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.
Tipp für PostgreSQL: www.pg-forum.de

Ich934
Lazarusforum e. V.
Beiträge: 264
Registriert: So 5. Mai 2019, 16:52
OS, Lazarus, FPC: ArchLinux und Windows mit FPCUPdeluxe (L: 2.0.X, FPC 3.2.0)
CPU-Target: x86_64, i386
Wohnort: Bayreuth

Re: SQLite: Darstellung Datum anders als Speicherung in Datenbank

Beitrag von Ich934 »

Winni hat geschrieben:
Di 23. Nov 2021, 10:13
Ich934 hat geschrieben:
Di 23. Nov 2021, 09:30
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!
Tipp für PostgreSQL: www.pg-forum.de

Antworten