FirebirdSQL logo

Konvertierung von Datentypen

Beim Verfassen eines Ausdrucks oder der Angabe einer Operation sollte das Ziel sein, kompatible Datentypen für die Operanden zu verwenden.Wenn eine Mischung von Datentypen verwendet werden muss, sollten Sie nach einer Möglichkeit suchen, inkompatible Operanden zu konvertieren, bevor Sie sie der Operation unterziehen.Die Möglichkeit, Daten zu konvertieren, kann durchaus ein Problem darstellen, wenn Sie mit Dialekt-1-Daten arbeiten.

Explizite Datentypkonvertierung

Die CAST-Funktion ermöglicht die explizite Konvertierung zwischen vielen Paaren von Datentypen.

Syntax
CAST (<expression> AS <target_type>)

<target_type> ::= <domain_or_non_array_type> | <array_datatype>

<domain_or_non_array_type> ::=
  !! Vgl. Syntax für Scalardatentypen !!

<array_datatype> ::=
  !! Vgl. Syntax für Array-Datentypen !!

Siehe auch CAST() im Abschnitt Eingebaute Skalarfunktionen.

docnext count = 7

Casting auf eine Domain

Beim Casting in eine Domäne werden alle dafür deklarierten Constraints berücksichtigt, d. h. NOT NULL- oder CHECK-Constraints.Wenn der Wert die Prüfung nicht besteht, schlägt die Umwandlung fehl.

Wenn zusätzlich TYPE OF angegeben wird — Umwandlung in seinen Basistyp — werden alle Domäneneinschränkungen während der Umwandlung ignoriert.Wird TYPE OF mit einem Zeichentyp (CHAR/VARCHAR) verwendet, bleiben Zeichensatz und Kollatierung erhalten.

Casting in Spaltentyp

Wenn Operanden in den Typ einer Spalte umgewandelt werden, kann die angegebene Spalte aus einer Tabelle oder einer Sicht stammen.

Es wird nur der Typ der Spalte selbst verwendet.Bei Zeichentypen enthält die Besetzung den Zeichensatz, aber nicht die Sortierung.Die Einschränkungen und Standardwerte der Quellspalte werden nicht angewendet.

Beispiel
CREATE TABLE TTT (
  S VARCHAR (40)
  CHARACTER SET UTF8 COLLATE UNICODE_CI_AI
);
COMMIT;

SELECT
  CAST ('I have many friends' AS TYPE OF COLUMN TTT.S)
FROM RDB$DATABASE;

Konvertierungen für die CAST-Funktion möglich

Table 1. Umwandlungen mit CAST
Von Datentyp Zu Datentyp

Numerische Typen

Numerische Typen, [VAR]CHAR, BLOB

[VAR]CHAR

[VAR]CHAR, BLOB, Numerische Typen, DATE, TIME, TIMESTAMP, BOOLEAN

BLOB

[VAR]CHAR, BLOB, Numerische Typen, DATE, TIME, TIMESTAMP, BOOLEAN

DATE, TIME

[VAR]CHAR, BLOB, TIMESTAMP

TIMESTAMP

[VAR]CHAR, BLOB, DATE, TIME

BOOLEAN

BOOLEAN, [VAR]CHAR, BLOB

Um String-Datentypen in den Typ BOOLEAN zu konvertieren, muss der Wert (ohne Berücksichtigung der Groß-/Kleinschreibung) 'true' oder 'false' oder NULL sein.

Important

Beachten Sie, dass ein teilweiser Informationsverlust möglich ist.Wenn Sie beispielsweise den Datentyp TIMESTAMP in den Datentyp DATE umwandeln, geht der Zeitteil verloren.

Datum-Zeit-Formate

Um String-Datentypen in die Datentypen DATE, TIME oder TIMESTAMP umzuwandeln, muss das String-Argument eines der vordefinierten Datums- und Uhrzeitliterale sein (siehe [fblangref40-dtyp-tbl-datetimemnemonics-de]) oder eine Darstellung des Datums in einem der zulässigen Datum-Uhrzeit-Literal-Formate (siehe Datumzeit-Format-Syntax),

Table 1. Vordefinierte Datum/Uhrzeit-Mnemonik

Literal

Beschreibung

'NOW'

Aktuelle Zeit und Datum

'TODAY'

Aktuelles Datum

'TOMORROW'

Aktuelles Datum + 1 (Tag)

'YESTERDAY'

Aktuelles Datum - 1 (Tag)

Note

Das Umwandeln der Datumsmnemonik 'TODAY', 'TOMORROW' oder 'YESTERDAY' in einen TIMESTAMP WITH TIME ZONE erzeugt einen Wert um 00:00:00 UTC, basierend auf der Sitzungszeitzone.

Zum Beispiel erzeugt cast('TODAY' as timestamp with time zone) on 2021-05-02 20:00 - 2021-05-03 19:59 New York (oder 2021-05-03 00:00 - 2021-05- 03 23:59 UTC) mit der Sitzungszeitzone America/New_York den Wert TIMESTAMP '2021-05-02 20:00:00.0000 America/New_York'. Dementgegen erzeugt cast('TODAY' as date) oder CURRENT_DATE ` je nach aktuellem Datum entweder `DATE '2021-05-02' oder DATE '2021-05-03'.

Wörtliche Interpretationen des Beispieldatums
select
  cast('04.12.2014' as date) as d1, -- DD.MM.YYYY
  cast('04 12 2014' as date) as d2, -- MM DD YYYY
  cast('4-12-2014' as date) as d3,  -- MM-DD-YYYY
  cast('04/12/2014' as date) as d4, -- MM/DD/YYYY
  cast('04.12.14' as date) as d5,   -- DD.MM.YY
  -- DD.MM with current year
  cast('04.12' as date) as d6,
  -- MM/DD with current year
  cast('04/12' as date) as d7,
  cast('2014/12/04' as date) as d8, -- YYYY/MM/DD
  cast('2014 12 04' as date) as d9, -- YYYY MM DD
  cast('2014.12.04' as date) as d10, -- YYYY.MM.DD
  cast('2014-12-04' as date) as d11, -- YYYY-MM-DD
  cast('4 Jan 2014' as date) as d12, -- DD MM YYYY
  cast('2014 Jan 4' as date) as dt13, -- YYYY MM DD
  cast('Jan 4 2014' as date) as dt14, -- MM DD YYYY
  cast('11:37' as time) as t1, -- HH:mm
  cast('11:37:12' as time) as t2, -- HH:mm:ss
  cast('11:31:12.1234' as time) as t3, -- HH:mm:ss.nnnn
  -- DD.MM.YYYY HH:mm
  cast('04.12.2014 11:37' as timestamp) as dt1,
  -- MM/DD/YYYY HH:mm:ss
  cast('04/12/2014 11:37:12' as timestamp) as dt2,
  -- DD.MM.YYYY HH:mm:ss.nnnn
  cast('04.12.2014 11:31:12.1234' as timestamp) as dt3,
  cast('now' as timestamp) as m1,
  cast('today' as date) as m2,
  cast('yesterday' as date) as m3,
  cast('tomorrow' as date) as m4
from rdb$database

Kurzformumwandlungen für Datums- und Zeitdatentypen

Firebird erlaubt die Verwendung einer abgekürzten Typsyntax im C-Stil für Umwandlungen von Strings in die Typen "DATE", "TIME" und "TIMESTAMP".Der SQL-Standard ruft diese Datetime-Literale auf.

Syntax
<data_type> 'date_format_string'
Note

Diese Literalausdrücke werden beim Parsen direkt ausgewertet, als ob die Anweisung bereits für die Ausführung vorbereitet wäre.Da dies bei der Verwendung von Datetime-Mnemoniken wie 'NOW' zu unerwarteten oder verwirrenden Ergebnissen führte, insbesondere in PSQL-Code, sind die Datetime-Mnemoniken in Datetime-Literalen seit Firebird 4.0 nicht mehr erlaubt.

Um Datetime-Mnemonik zu verwenden, verwenden Sie die vollständige CAST-Syntax.Ein Beispiel für die Verwendung eines solchen Ausdrucks in einem Trigger:

NEW.CHANGE_DATE = CAST('now' AS TIMESTAMP);

Implizite Datentypkonvertierung

Eine implizite Datenkonvertierung ist in Dialekt 3 nicht möglich — die CAST-Funktion wird fast immer benötigt, um Datentypkonflikte zu vermeiden.

In Dialekt 1 wird in vielen Ausdrücken ein Typ implizit in einen anderen umgewandelt, ohne dass die CAST-Funktion verwendet werden muss.Zum Beispiel gilt die folgende Aussage in Dialekt 1:

UPDATE ATABLE
  SET ADATE = '25.12.2016' + 1

Das Datumsliteral wird implizit in den Datumstyp umgewandelt.

In Dialekt 3 wird diese Anweisung den Fehler 35544569 ausgeben, “`Dynamic SQL Error: expression evaluation not supported, Strings cannot be added or subtracted in dialect 3” — eine Umwandlung ist erforderlich:

UPDATE ATABLE
  SET ADATE = CAST ('25.12.2016' AS DATE) + 1

Oder mit einem Datetime-Literal:

UPDATE ATABLE
  SET ADATE = DATE '25.12.2016' + 1

In Dialekt 1 ist es normalerweise möglich, ganzzahlige Daten und numerische Zeichenfolgen zu mischen, da der Parser versucht, die Zeichenfolge implizit umzuwandeln.Beispielsweise,

2 + '1'

wird korrekt ausgeführt.

In Dialekt 3 führt ein solcher Ausdruck zu einem Fehler, daher müssen Sie ihn als CAST-Ausdruck schreiben:

2 + CAST('1' AS SMALLINT)

Die Ausnahme von der Regel ist während der String-Verkettung.

Implizite Konvertierung während der String-Verkettung

Wenn mehrere Datenelemente verkettet werden, werden alle Nicht-String-Daten nach Möglichkeit implizit in Strings umgewandelt.

Beispiel
SELECT 30||' days hath September, April, June and November' CONCAT$
  FROM RDB$DATABASE;

CONCAT$
------------------------------------------------
30 days hath September, April, June and November