DbGrid Integer-Wert als Datum anzeigen

[BadenPower]

Ich glaube mein Gehirn macht eine Pause oder ich hab irgendetwas übersehen und benötige deshalb einige Anregungen von Euch.


Der Zugiff auf eine Tabelle in der Datenbank erfolgt über Zeos mit einer ZTable-Komponente.

An der ZTable hängt eine DataSource.
An der DataSource hängt auch ein DBGrid.

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.

Also sollte die Tabelle praktisch ein zusätzliches virtuelles Datums-Feld erhalten, welches seinen Wert aus dem Integer-Feld berechnet.

Das Problem (oder vielleicht auch nicht) an der ganzen Sache ist, dass die Tabelle nicht nur zwingend vorgegebene Felder enthält, sondern von den Nutzern erweitert werden kann und automatisch vom System bei zusätzlichen installierbaren Sprachen erweitert wird.

Das Einzige, was mir eingefallen ist, ist eine weitere Query für jede Tabelle zu erstellen und diese vorab zu öffnen, um die Felddefinitionen der Tabelle in die ZTable zu kopieren und das Zusatzdatumsfeld hinzufügen.

Mir fehlt im Moment einfach die zündende Idee.

Es ist alles an Anregung oder Code-Beispielen zur Kalkulation oder Erstellung des Feldes willkommen.

Also egal was Euch einfällt, ersteinmal her damit.

Mal schauen, was ich daraus dann machen kann, oder ob ich feststellen muss, dass sich wirklich nur eine Gehirnwindung verknotet hat.

vielen Dank
BadenPower

[mm1256]

Hallo,

zum Feld anzeigen würde ich TDBGrid.OnDrawColumnCell nehmen

Delphi-Quellcode:

  ..
  if Column.FieldName = 'DasDatumFeld' then
  with (Sender as TDBGrid).Canvas do begin
    if State = [gdSelected] then begin
      Brush.Color := clHighLight;
      Pen.Color := clHighLightText;
    end else begin
      Brush.Color := DBGrid.Color;
      Pen.Color := DBGrid.Font.Color;
    end;
    FillRect(Rect);
    TextOut(Rect.Left, Rect.Top,'DatumAusIntegerBerechnet');
  end;

Nicht getestet..aber so ähnlich müsst es tun. Zum Editieren: Soll das direkt im DBGrid stattfinden?

[baumina]

Nur mal so ne Idee: Gleich mit der DB-Abfrage ein Datumsfeld erhalten, durch casten auf varchar und der mySQL-Funktion STR_TO_DATE.

[Gollum]

Hallo,

wieso benutzt Du nicht OnGetText und OnSetText von TField?

Siehe auch Data.DB.TField.OnGetText.

[Sir Rufo]

Mal doof gefragt:

In der Tabelle ist ein Integer-Feld und die Tabelle kann erweitert werden. Woran erkennst du ob du dieses Feld jetzt wie ein Datum behandeln musst oder eben doch als einfachen Integer?

Da müsste es jetzt zusätzliche Meta-Daten geben, aus denen du dann eine Tabelle aufbauen kannst und dann mit den Werten aus der echten Tabelle (inkl. Konvertierung) füllst.

[BadenPower]

Zitat:

Zitat von mm1256 (Beitrag 1304867)

Nicht getestet..aber so ähnlich müsst es tun. Zum Editieren: Soll das direkt im DBGrid stattfinden?

Ja, die Möglichkeit zum Editieren im Grid sollte erhalten bleiben.

Zitat:

Zitat von baumina (Beitrag 1304868)

Nur mal so ne Idee: Gleich mit der DB-Abfrage ein Datumsfeld erhalten, durch casten auf varchar und der mySQL-Funktion STR_TO_DATE.

Hatte ich auch schon in Betracht gezogen.

Allerdings handelt es sich um eine TZTable, wodurch ein manueller Eingriff programmierseitig nicht erforderlich ist und dann müßte ich das SQL-Statement selbst festlegen.
Und da es sich dabei noch um eine Detail-Tabelle in einer Master-Detail-Beziehung handelt wollte ich mir das Erstellen der Statements ersparen.

Zitat:

Zitat von Gollum (Beitrag 1304870)

wieso benutzt Du nicht OnGetText und OnSetText von TField?

Die Frage stelle ich mir auch gerade.
:thumb::thumb::thumb:
Hätte man auch selbst drauf kommen können.

Das könnte durchaus die einfachste und praktikabelste Lösung sein.


Irgendwelche anderen Vorschläge oder Anregungen???

[BadenPower]

Zitat:

Zitat von Sir Rufo (Beitrag 1304871)

Woran erkennst du ob du dieses Feld jetzt wie ein Datum behandeln musst oder eben doch als einfachen Integer?

Bei den erweiterten Feldern ist dies nicht erforderlich, da nicht vorgesehen.

Es wird zwar in den Formularen die Möglichkeit geboten die durch den Nutzer erweiterten Felder in DBMemo oder DBEdit je nach Datentyp und im DBGrid zu editieren, aber es findet keine Formatierung der Ausgabe/Eingabe statt.

Dies betrifft nur die in der Grundsoftware zwingend vorgegebnen Datenbankfelder. Und dort ist der Datentyp und der Verwendungszweck klar definiert.

Zitat:

Zitat von Sir Rufo (Beitrag 1304871)

Da müsste es jetzt zusätzliche Meta-Daten geben, aus denen du dann eine Tabelle aufbauen kannst und dann mit den Werten aus der echten Tabelle (inkl. Konvertierung) füllst.

Dass ist eine gute Idee und mal schauen, ob ich so etwas noch einbauen werde, nach dem Motto:

"Wenn Du etwas erweiterst und eine gewisse Anzeige/Formatierung haben möchtest, dann hinterlege dies in einer Datenbank."

[Dejan Vu]

Kann mySQL 'updateable views'? Dann wäre das ein denkbarer Weg. Die View zeigt die Daten so an, wie sie editiert werden sollen. Um Instead-Of-Trigger der View konvertierst du dann die Daten wieder in den Originalwert.

Diese View kannst Du auch automatisch erstellen, anhand der Metadaten oder was auch immer Du für Informationen hast.

[BadenPower]

Zitat:

Zitat von Dejan Vu (Beitrag 1304877)

Kann mySQL 'updateable views'? Dann wäre das ein denkbarer Weg. Die View zeigt die Daten so an, wie sie editiert werden sollen.

Auch ein guter Ansatz, aber für meinen Fall nicht unbedingt dass was ich haben möchte, da ich an der Datenbankstruktur selbst nichts verändern möchte.

Es kann durchaus vorkommen, dass die gesamte Datenbank zusätzlich als Mirror auf einem anderen DBMS läuft, als die Life-Daten und die Arbeitsdaten. Im ungünstigsten Fall habe ich dann 3 verschiedene Datenbanksysteme, welche übergreifend mit den selben Formularen abgedeckt werden müssen.

[Dejan Vu]

Das hatte ich befürchtet.

Zitat:

Zitat von Gollum (Beitrag 1304870)

wieso benutzt Du nicht OnGetText und OnSetText von TField?

Wenn das TDBDateTimeEdit mitmacht, wäre das die Lösung: Immerhin handelt es sich um ein TIntegerField.

Du könntest die Daten auch in einem TClientDataset vorhalten, dem Du ein TDateTimeField spendiert hast (und eventuell weitere Felder). Das lohnt sich dann, wenn Du die Daten eh von Hand persistierst.

[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