Das sollte eigentlich nur knallen wenn die Daten aus der
DB als String gelesen und von dir in den jeweiligen Typen gewandelt werden.
Du solltest dich in dem Schritt also auf ein Format für Dezimalzahlen und Datums-/Zeitangaben festlegen.
Eine kleine statische Factory, die dir IFormatProvider generiert (einen für Zahlen und einen für Datumswerte) so dass du die Werte aus der
DB immer mit dem richtigen Format parsen kannst.
Ob du es nun als Factory oder statische proprties machst ist Jacke wie Hose (Um Michaelaus der SB zu zitieren
). Hauptsache ist, dass jeder String, der nicht innerhalb der aktiven Culture generiert wurde, auf keinen Fall ohne richtigen FormatProvider in einen Wertetyp gewandelt wird.
Alles was innerhalb einer Culture passiert sollte[1] konsistent, ohne dein Zutun kompatibel sein.
Natürlich musst du die Werte auch wieder mit den Formaten deiner
DB in Strings wandeln, wenn du sie in der
DB als Strings haben willst. Nur so kannst du sicherstellen, dass du sie mit dem Format auch wieder auslesen kannst.
btw: Wenn du lieber ohne diese ganzen String->Wert->String-Friemeleien auskommen könntest, würde sicherlich alles flinker und runder laufen.
Und nun das obligatorische: Warum schreibst du jetzt noch eine ASPX1.1 Anwendung und viel interessanter: Warum benutzt du den BDP für Firebird?
Der Firebird provider (in der jeweiligen stable Version) gehört
IMHO zu den besten Daten providern in .Net überhaupt.
Er lässt sogar, allein vom Funktionsumfang, sämtliche
IB/
FB-Bibliotheken für native Delphi absolut alt aussehen.
[1]"sollte" ist keine Garantie