![]() |
Datenbank: Access • Version: 12.0 • Zugriff über: FireDAC
Sprachabhängige Formatstrings im Datenmodul?
Ein
Delphi-Quellcode:
hängt an einem
TDBGrid
Delphi-Quellcode:
hängt an einem
TDataSource
Delphi-Quellcode:
. Normaler Alltag.
TDataSet
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
Delphi-Quellcode:
eine schöne Eigenschaft
TSQLTimeStampField
Delphi-Quellcode:
für das man gleich einen Format-String für die Zeitangabe reinpacken kann.
DisplayFormat
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. |
AW: Sprachabhängige Formatstrings im Datenmodul?
Zitat:
Delphi-Quellcode:
?:mrgreen:
TDBGrid
Aber im Ernst, ich nutze dafür eine SQLProcedure, die ungefähr so aufgebaut ist
Delphi-Quellcode:
Da ich das für Brieferzeugung nutze, darf es auch Teil der DB sein
case LC of
'US': to_char(input,'MM,DD,YYYY') 'DE': to_char(input,'DD.MM.YYYY') end; 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 |
AW: Sprachabhängige Formatstrings im Datenmodul?
Zitat:
Ob ich das jetzt in einen Delphi-TField oder der SQL-Query steckt- Finde ich, ist doch im Endeffekt das gleiche. |
AW: Sprachabhängige Formatstrings im Datenmodul?
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. |
AW: Sprachabhängige Formatstrings im Datenmodul?
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. |
AW: Sprachabhängige Formatstrings im Datenmodul?
Zitat:
Delphi-Quellcode:
des Feldes einfach
DisplayFormat
Delphi-Quellcode:
zuzuweisen.
FormatSettings.LongTimeFormat
|
AW: Sprachabhängige Formatstrings im Datenmodul?
@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. |
AW: Sprachabhängige Formatstrings im Datenmodul?
Zitat:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:02 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz