Welches DateTime Format schluckt jede Datenbank?

[dummzeuch]

Zitat von HeZa:

Zitat von Delphi.Narium:

...Geht dashier bei allen Datenbanken? W3Schools - SQL Working With Dates...

Ein Datum mit Uhrzeit im ISO-Format sollten eigentlich viele Datenbanken schlucken können (z.B. 2020-09-17 16:24:33).

Oha, das ist aber optimistisch gedacht.

Selbst aktuelle Datenbanken dürften da noch Probleme machen, da kommt es ggf. darauf an, was der Admin eingestellt hat.

z.B. kennt MS-SQL auch so völlig bescheuerte Formate wie '09-17-20', was man natürlich auf den ersten Blick als amerikanisches Datumsformat (MM/TT/YY) mit '-' statt '/' erkennt. Quasi das schlimmste, was man sich ausdenken kann. Und glaube bloß nicht, dass das keiner so einstellt (Woher wüsste ich das sonst?)

[TigerLilly]

"Jede" sind ziemlich viele
Aber die meisten sollte schon gehen.

SQL 92 ist der Standard, an den die meisten Systeme sich halten:
https://www.ibphoenix.com/resources/...design/doc_169

[haentschman]

Moin...

Zitat:

MSSQL macht zum Beispiel beim Generieren von Importskripten immer sowas: INSERT ... VALUES(12, 'abc', cast('25.04.2020 14:55:22' as DateTime2))

Das ganze verstehe ich nicht. Die Datenbank bekommt immer einen TDateTime(Double) Wert... Damit ist das Thema Datenbank erledigt. Ob das eine Meier-Müller DB ist, TDateTime ist TDateTime.

Zitat:

sondern um ein ganz kleines Importskript

Der Importer muß das Format erkennen und umwandeln in TDateTime.

...oder habe ich was verpaßt?

[mkinzler]

Wenn es über ein (Delphi-)Programm geht dann ja. Es scheint hier aber um die Möglichkeit zu gehen, Skripte zur Anlage direkt auf die DB auszuführen.

[haentschman]

Zitat:

Es scheint hier aber um die Möglichkeit zu gehen, Skripte zur Anlage direkt auf die DB auszuführen.

...ok. Könnte man sich nicht im Setup ein Konsolen Programm aufrufen, was die DB Einträge macht. SQL mit Parametern laden, rein in Query...fertsch.

[HolgerX]

Hmm..

Es ist eigentlich NIE gut ein Datum als String in einem SQL Befehl anzugeben.
Ob und wie der String dann in ein Datum gewandelt wird hängt nicht nur vom verwendeten Datenbanksystem ab, sondern auch z.B. von der installierten Sprache des Datenbankserver.

Ein MS SQL-Server interpretiert ein Datum nach der installierten Sprache unterschiedlich. So kann es dazu kommen, dass Monat und Tag vertauscht werden.

Somit musst Du wohl SQL-Scripte angepasst für das Datenbanksystem bereitstellen.
Für SQL-Server z.B. durch Verwendung von convert:

convert(datetime,'2020.05.15 07:00:00',120)

Die 120 gibt bei der Konvertierung des Strings in das Datetime dann dessen Format an.
So ist sichergestellt, dass das Datum auch bei fremdsprachigen SQL-Servern korrekt übernommen wird.

[generic]

Es gibt noch das ODBC Date-Format:

Code:

{d'2020-12-30'}

update meineTabelle set datumsFeld={d'2020-12-30'}

das versteht u.a. der MSSQL
https://docs.microsoft.com/en-us/sql...l-server-ver15

und MYSQL
https://dev.mysql.com/doc/refman/8.0...-literals.html
.


Anstelle von d "datum" kann auch t "time" oder auch ts "timestamp" genutzt werden.

[Rollo62]

Es bestünde noch die Möglichkeit YY, MM, DD, HH, NN, SS alle in separate numerische Felder zu legen.
Das sollte jede DB hinbekommen, muss man dann aber auch zerlegen/zusammensetzen,
sollte aber auf jedenfall überall sicher sein.

[generic]

So wie ich Thomas verstehe, möchte er *ein* SQL-Skript erstellen, welches die DB unabhängig vom verwendeten Server anlegen kann.
Es natürlich einfacher als Skripte für jedes System pflegen zu müssen.

[Bernhard Geyer]

Zitat von Rollo62:

Es bestünde noch die Möglichkeit YY, MM, DD, HH, NN, SS alle in separate numerische Felder zu legen.
Das sollte jede DB hinbekommen, muss man dann aber auch zerlegen/zusammensetzen,
sollte aber auf jedenfall überall sicher sein.

Und dann auf alle schönen SQL-Funktionen verzichten die mit Datum/Uhrzeitangaben rechnen können.
Das wäre mir persönlich doch ein zu großer Nachteil.

Bei uns nutzen String und das ISO-Format.
Dann geht immerhin Sortierung "out of the box" korrekt.