DbGrid Integer-Wert als Datum anzeigen

[p80286]

Zitat:

Zitat von BadenPower (Beitrag 1304866)

Das Grid soll nun anstatt den Integer-Wert (z.B. 20061001) eines Feldes ein Datums-Feld (01.10.2006) anzeigen und auch als Datums-Feld editierbar sein.

Äh

Delphi-Quellcode:

20061001

ist die Kurzform von

Delphi-Quellcode:

2006-10-01

auch bekannt als ISO-Datum DIN ISO 8601 was der alten Schreibweise

Delphi-Quellcode:

1.10.2006

entspricht. Ist übrigens auch in Deutschland gültige norm, aber die PS sind ja auch nicht auszurotten.

Bei

Delphi-Quellcode:

20061001

handelt es sich nicht um eine Zahl sondern um eine Ziffernreihe, die ein Datum darstellt. Und somit vebieten sich erst einmal alle üblichen mathematischen Operationen!

Gruß
K-H

[BadenPower]

Zitat:

Zitat von p80286 (Beitrag 1304935)

Bei

Delphi-Quellcode:

20061001

handelt es sich nicht um eine Zahl sondern um eine Ziffernreihe, die ein Datum darstellt.

Das ist das was wir (also Du und ich) daraus interpretieren.
Für die Datenbank ist es ein Integer, also eine Zahl.

Zitat:

Zitat von p80286 (Beitrag 1304935)

Und somit vebieten sich erst einmal alle üblichen mathematischen Operationen!

Die Umwandlung selbst steht ja nicht zur Debatte, dann das ist eine Standard-Routine, welche ich schon seit Jahren benutze.

[EDIT]
Wer ein Code-Snipsel für die Umwandlung hat, darf es auch gerne posten.
Da gibt es bestimmt zahlreiche Lösungsansätze, welche durchaus interessant sein könnten, da man vielleicht auf diesen Lösungsweg nicht selbst gekommen ist.
[/EDIT]

Zitat:

Zitat von p80286 (Beitrag 1304935)

aber die PS sind ja auch nicht auszurotten.

Ich hätte auch lieber gerne ein schönes echtes Datumsfeld.
Aber zeig mir mal eine praktikable Lösung um gleichzeitig in verschiedenen Programmiersprachen zu rechnen/sortieren und darzustellen und in verschiedenen Datenbank-Systemen einheitlich einen Datumswert für "15. Dezember 200 vor Christus" bis "31.12.2599" zu speichern, welcher auch ohne Umwandlungsroutine noch vernünftig von Hand lesbar ist.


Momentan sieht es gut für die Field-Events aus, Sieger zu werden.

[p80286]

Zitat:

Zitat von BadenPower (Beitrag 1304939)

Das ist das was wir (also Du und ich) daraus interpretieren.
Für die Datenbank ist es ein Integer, also eine Zahl.

Schwierig bei so einem Thema jemanden nicht auf die Füße zu treten, aber wenn in dem "Datumsfeld" nicht ein numerisch kodiertes Datum drinsteht, a la Tage seit Christi Geburt, dann sollte das Feld auch nicht numerisch sein. Ob char,varchar, text oder was auch immer stattdessen, ist mir egal.
(diese Besserwisserei von Exel hat Spuren hinterlassen)
für eine Oracledb würde ich in diese fall folgendes machen:

SQL-Code:

select to_date(to_char(feld,'99999999'),'YYYYMMDD') from....

Dann hast du als Ausgabe ein Datum(zeitangabe) wenn's für ein Stringgrid sein soll dann:

SQL-Code:

select to_char(to_date(to_char(feld,'99999999'),'YYYYMMDD'),'DD.MM.YYYY') from....

ein wenig unübersichtlich, sollte aber funktionieren.

Gruß
K-H

[Dejan Vu]

Oh, ich bin gerade zum Review bei einem Anbieter, der seit 30 Jahren Software im Bankenumfeld für unterschiedliche DB-Systeme entwickelt. Die speichern die Datumswerte genauso wie B-Pow :mrgreen: (20061001) stellen aber langsam auf BIGINT (Ticks) um (was ja irgendwie noch perverser ist). :shock:
Wieso? Weil das datenbankunabhängig ist, sagen sie. Rechnen kann man damit, und da man sowieso nicht direkt auf die Tabelle zugreift, sondern nur über SP und Views, ist das eh wurscht. Ich meine, das ist echt kein Kindergarten hier.

Was ich damit sagen will: Es soll Leute geben, die das so machen. Und nicht, weil sie blöd sind, sondern sich irgend etwas dabei gedacht haben.

Und wenn ein Feld nunmal so ist, dann muss man damit leben und das beste draus machen. Genau das wird hier versucht.

[p80286]

erst einmal

Zitat:

Zitat von BadenPower (Beitrag 1304939)

Ich hätte auch lieber gerne ein schönes echtes Datumsfeld.

weist meiner Meinung nach darauf hin, daß er eine Altlast übernommen hat, an der er nichts ändern kann.
Schade ist aber so.

Historisch gesehen, Datumsangaben wurden zumindest bei der IBM auch gerne in BCD-Feldern abgelegt, und nicht umsonst gab es den dummen Spruch "da hat jemand das Datum dazu addiert".
Wenn ee einnumerisches Feld sein muß, dann doch bitte eins in dem ein Zähler von was auch immer (Sekunden, Tage, Ticks) seit einem definierten Nullpunkt steht.
Falls jemand auf die Idee kommt 20151224-(2015*365) zu rechnen, dann landet er bei 19415749 und das ist glaube ich kein gültiges Datum und nicht Christi Geburt.:stupid:

Gruß
K-H

[himitsu]

Zitat:

Zitat von Dejan Vu (Beitrag 1304961)

Rechnen kann man damit.

Eigentlich nein, oder was kommt bei 20150228 + 1 raus?

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1304972)

Zitat:

Zitat von Dejan Vu (Beitrag 1304961)

Rechnen kann man damit.

Eigentlich nein, oder was kommt bei 20150228 + 1 raus?

Können kann man, das ist ja das Dumme...

Gruß
K-H

[BadenPower]

Zitat:

Zitat von p80286 (Beitrag 1304958)

Schwierig bei so einem Thema jemanden nicht auf die Füße zu treten,

Du kannst Deine Meinung gerne vertreten und ich werde mich deshalb bestimmt nicht auf die Füße getreten fühlen.


Jetzt einmal zu den Grundvorraussetzungen:

1. Datenbanksysteme

1. MySql
2. PhpMySql
3. MariaDb
4. Firebird
5. und theoretisch irgendwann einmal alles was Zeos bietet

2. Das Datum soll auch ohne "Konverter" einigermaßen vernünftig lesbar und editierbar (im Adminmodus mit Direktzugriff auf die Tabellen also als ShowAsIsInDatabase) sein. Also kein Timestamp.

3. Es soll alle Dati darstellen können

4. Ist kein Datum bekannt, dann soll es entspechend gespeichert werden können (in diesem Fall einfach eine 0)

5. Wurden noch keine Angaben gemacht, dann ist es NULL

6. Es sollte/muss in verschiedenen Programmiersprachen (PHP/Perl/Delphi) eine Möglichkeit geben diese Dati in Variabeln zur weiteren Verarbeitung abzulegen und zwar so, dass ich nicht jedesmal überlegen muss wo ich gerade bin, bzw. so dass die Verarbeitungsroutinen identisch sind.

7. Wichig ist auch, dass auf das Erstellen von SQL-Statements verzichtet wird, da sonst die Unabhängigkeit von Datenbanksystem verloren gehen kann. Das machen die Kompenenten alles automatisch, was natürlich praktisch ist, wenn wie in diesem Formular an der Haupttabelle 12 Detail-Tabellen hängen, welche alle und dies sogar bis zu 4 solche "Datumsfelder" haben.


Dies waren auch mit die Gründe, sich vor Jahren für ein Integerfeld zu entscheiden.

Dejan Vu hat es dabei exakt auf den Punkt gebracht.:thumb:

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1304972)

Zitat:

Zitat von Dejan Vu (Beitrag 1304961)

Rechnen kann man damit.

Eigentlich nein, oder was kommt bei 20150228 + 1 raus?

Na, was meinst Du: Worauf bezog sich meine Bemerkung 'Rechnen kann man damit'?
[ ] 20150228
[ ] BIGINT

Hältst Du mich für blöd? ;-)

PS: 2.015.228 + 1 = 2.015.229... das weiß selbst mein Hamster.
(Siehst du, das kommt dabei raus, wenn man alles wörtlich nimmt).

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1304995)

PS: 2.015.228 + 1 = 2.015.229... das weiß selbst mein Hamster.

Intelligentes Tier davon könnte ich einen Klon brauchen.

Gruß
K-H