Dem kann ich auch nur explizit zustimmen.
Eine Datenbank speichert ihre Information i.d.R. unabhängig von jedweder Ländereinstellung!
Bei einer Dezimalzahl wählt man ja auch Numeric/Decimal/Double und weiß so, dass der Wert korrekt gespeichert wird unabhängig vom verwendeten Client, der nun einen Dezimalpunkt oder Dezimalkomma verwendet.
Ganz genauso verhält es sich auch mit den Typen Date/Time/Timestamp, die je nach Dialekt auch mal einwenig anders heißen.
Sobald man aber von der Typisierung seiner Daten weggeht kann man sich da nur Probleme einhandeln.
Bei der Datumdarstellung in der Form "TT.MM.JJJJ" scheitert man bereits an Sortierungen, Vergleichen wie >, <, between oder sogar Berechnungen.
Hierfür muss man dann wieder Klimmzüge mit Konvertierungen (Cast's) vornehmen, die dann auch noch kontraproduktiv bzgl. der Verwendung von Indizes sind.
Kommen wir nun zum Client:
Auch dort werden die Möglichkeiten von sprachneutralen Verwendungen häufig vernachlässigt!
Seit Einführung von SQL (Ende der 60er) gibt es bereits das Konzept der "Parametermarker".
D.h., dass grundsätzlich in allen SQL's mit variablen Daten Parametermarker zu verwenden sind!
Das unsägliche zusammenbauen von SQL's im Code macht die ganze Sache nur unnötig kompliziert und, vor allem, auch langsamer! Und es müssen ebenso die Eigenheiten der Datenbank berücksichtigt werden.
Hinzu kommt, dass eben Parametermarker ebenso sprachneutral sind. Jede Programmiersprache kennt ihre Datentypen, so dass diese auch in SQL verwendbar sind. Für eine korrekte Übersetzung zwischen Programmvariable und SQL ist letztlich dann der Treiber zuständig.
Wer kennt nicht das Problem, dass Zeichenketten, die ein Hochkomma enthalten, diese verdoppelt werden müssen? Mit Parametermarker vollkommen unnötig.
Wenn ich also eine Spalte vom Typ Date definiert habe, kann ich auch in meinem Programm die Variable vom Type Date/Datetime verwenden und diese dann dem jeweiligen Parameter direkt zuweisen.
Beim Auslesen der Daten erhalte ich auch direkt eine Variable vom Typ Date.
Dasselbe gilt im Übrigen ebenso der Verwendung von Unicode oder Nicht-Unicode.
Beispiel:
Insert into MyTable (F1, F2, F3) values(?, ?, ?)
Select * from MyTable where F1=? and F2 between ? and ? and F3 > ?
Je nach Treiber kann dieser ggf. schon die Parameter-Objekte automatisch erstellen.
Ansonsten gibt es dann Methoden, je "?" einen Parameter in der Reihenfolge zu definieren.
.NET unterstützt (mit DataAdapter und CommandBuilder) auch benannte Parameter:
Select * from MyTable where F1=@F1 and F2 between @F2A and @F2B and F3 > @F3
Zuguter letzt braucht sich der Client dann nur noch in der Präsentation und Eingabe um sprachrelevante Dinge zu kümmern, wobei hier die Regional-Settings dann auch ziehen (außer bei den sog. Invariant-Funktionen).
Und selbst dabei wird man automatisch durch die Frameworks bereits unterstützt.
Wie du siehst, eigentlich alles ganz Easy.
