Ein TDBGrid hängt an einem TDataSource hängt an einem TDataSet . Normaler Alltag.

Nun formatieren insbesondere unsere für Demokratie und Frieden kämpfenden Wohltäter auf der anderen Seite des großen Teichs Währungen oder Zeit nun einmal anders. Auch nichts neues.

Nur: Wo stecke ich jetzt die Sprach/Landesabhängigen Dinge wie Formatstrings hin? Ich kann beim DBGrid mit seinen Spalten nichts einstellen, am DataSource nichts, nur in den Feldern des TDataSets. Da hat mein Feld vom Typ TSQLTimeStampField eine schöne Eigenschaft DisplayFormat für das man gleich einen Format-String für die Zeitangabe reinpacken kann.

Aber hier rein sprachabhängige Dinge reinzupacken missfällt mir- Mein Datenmodul wollte ich eigentlich von der Optik nicht beinflussen lassen...

Gibt es noch andere Wege? Der DBGrid wird sich ja wahrscheinlich an den "globalen" Formatsettings der Anwendung orientieren- Aber in diesem Fall komme ich um einen Formatstring nicht herum da FireDAC von diesem Feld irgendwie immer ein volles Datum ausgibt mit Uhrzeit ausgibt, enthalten ist aber nur eine Uhrzeit.

Zitat von Der schöne Günther:

Aber hier rein sprachabhängige Dinge reinzupacken missfällt mir- Mein Datenmodul wollte ich eigentlich von der Optik nicht beinflussen lassen...

Und dann nutzt Du TDBGrid ?

Aber im Ernst, ich nutze dafür eine SQLProcedure, die ungefähr so aufgebaut ist

markieren

Delphi-Quellcode:

case LC of
  'US': to_char(input,'MM,DD,YYYY')
  'DE': to_char(input,'DD.MM.YYYY')
end;

Da ich das für Brieferzeugung nutze, darf es auch Teil der DB sein

Bei Rechercheergebnissen, gibt es grundsätzlich nur das ISO-Datum, das gefällt allen nicht, ist aber theoretisch bekannt.
(das ist wie mit PS und KW)

Gruß
K-H

Zitat von p80286:

Und dann nutzt Du TDBGrid ?

Für eine Alternative bin ich immer offen. Ich kenne mich in Sachen "Delphi und Datenbanken" nicht aus. Mir fehlt so eine Art FormatString-Property auf GUI-Ebene.

Ob ich das jetzt in einen Delphi-TField oder der SQL-Query steckt- Finde ich, ist doch im Endeffekt das gleiche.

Werte für Datum und Währung benötigen einen Kontext (welche Zeitzone, welche Währung) um korrekt interpretiert zu werden.
Diesen Kontext sollte man auch in der DB hinterlegen.

Und wenn man schon dabei ist, dann speichert man sich dort auch das Anzeigeformat ab.
Also eine einfache Key-Value-Tabelle und dort die ganzen Werte rein und im Programm verwenden.

Für mich sind alle TDB...-Komponenten PfuiBa weil sie unter Umständen ein Eigenleben entwickeln, da schiebe ich lieber meine Daten in normale Grids... und führe auch ganz bewußt einen Update(insert, update) durch.

Aber da finde ich hier nicht so viele Mitstreiter.

Zu Deinem Problem, es kommt darauf an. Wenn Du die Datums/Währungs...Angabe an den Benutzer, bzw. seine Ländereinstellung anpassen willst, dann nimm die üblichen irgendwastoStr-Routinen, denn die werten das Benutzer-Land aus.
Willst Du auf einem deutschen PC, Daten für Amerika produzieren,dann schieb zwischen Abfrage und Ausgabe (Grid) eine Formatierroutine ein.
(allerdings bezweifle ich, daß das nit DBGrid) überhaupt geht.
Aber eine abgeleitete Klasse....

Gruß
K-H

@Sir Rufo
Wenn du meinst "in einer DB" stimme ich Dir voll zu, warum sollte ich in 10 DBs 10 mal allgemeine Formatinfos hinterlegen? Das ist nur notwendig wenn ich für eine DB spezielle Formatinformationen benötige.

Zitat von Der schöne Günther:

Aber in diesem Fall komme ich um einen Formatstring nicht herum da FireDAC von diesem Feld irgendwie immer ein volles Datum ausgibt mit Uhrzeit ausgibt, enthalten ist aber nur eine Uhrzeit.

Vielleicht genügt es, dem DisplayFormat des Feldes einfach FormatSettings.LongTimeFormat zuzuweisen.

@p80286

Es kommt nicht auf die Anzahl der DBs an, sondern auf den Gültigkeitsbereich des Kontexts.

10 verschiedene Datenbanken mit dem gleichen Kontext benötigen auch nur einmal diese Information.
Ist der Kontext pro Datensatz unterschiedlich, benötigt man diese Information pro Datensatz.

Zitat von p80286:

Willst Du auf einem deutschen PC, Daten für Amerika produzieren,dann schieb zwischen Abfrage und Ausgabe (Grid) eine Formatierroutine ein.
(allerdings bezweifle ich, daß das nit DBGrid) überhaupt geht.

Grade da finde ich nichts. Die "optischen" Eigenschaften hängen alle im DataSet, also ziemlich früh.

Zitat von Uwe Raabe:

Vielleicht genügt es, dem DisplayFormat des Feldes einfach FormatSettings.LongTimeFormat zuzuweisen.

Das genügt sogar höchstwahrscheinlich.