Wie Char-Feld/Domäne in Firebird 3 Boolean-Feld wandeln?

[BlueStarHH]

Hallo,

ich habe meine DB von Firebird 2 auf Firbird 3 umgestellt. In meinen Tabellen verwende ich einen eigenen Datentyp MYBOOL für Boolean-Felder, da es in Firebird 2 kein Boolean gab. Die Definition dafür sieht so aus:

Delphi-Quellcode:

CREATE DOMAIN MYBOOL AS
CHAR(1) CHARACTER SET ISO8859_1
CHECK ((VALUE IS NULL) OR (VALUE IN ('F','T')))
COLLATE ISO8859_1;

Benutzt wird das z.B. so:

Delphi-Quellcode:

CREATE TABLE EINE_TABELLE (
..
    EIN_FELD    MYBOOL DEFAULT 'F'
)

In Firebird 3 gibt es nun Boolean als Datentyp. Wie kann ich alle meine "MYBOOL"-Felder per SQL auf den neuen Datentyp umstellen? Möglichst ohne viel manuell machen zu müssen, da ich etwa 100 Tabellen mit 150 MYBOOL-Feldern habe.

[hoika]

Hallo,
meine Frage ist und bleibt, warum etwas ändern was funktioniert?

Ansonsten:
https://stackoverflow.com/questions/...e-in-firebird3

[BlueStarHH]

Zitat von hoika:

Hallo,
meine Frage ist und bleibt, warum etwas ändern was funktioniert?

Richtig funktionieren tut es an einigen Programmstellen eben nicht. Da braucht man Workarounds. Aber das ist ein anderes Thema, was ich hier nicht diskutieren möchte. Und einen Mix aus dem neuen Bool-Datentyp und meinem eigenen ist auch nicht optimal. Also alles besser auf den neuen Bool umstellen.

Zitat von hoika:

Hallo,
Ansonsten:
https://stackoverflow.com/questions/...e-in-firebird3

Mit alter column type wird das nicht funktionieren, da ich eine selbstdefinierte Domain (Datentyp) habe, und FB nicht weiß, wie die nach Boolean umgewandelt werden soll.

[mkinzler]

Dann wird dir nichts anderes übrig bleiben, als die Umstellung in mehreren Phasen durchzuführen.
-Einfügen neuer Spalten
-Kopie der Werte von alter auf neue Spalte 'J' -> True
(-Behandlung wenn FK andere Tabellen auf derartige Spalten)
-Löschen der alten Spalten
-Umbenennung der neuen Spalten

[MyRealName]

Wenn du keine Trigger, Views oder Stored Procs hast, die eventuell Abhängigkeiten auf diese Felder haben, dann kannst Du das mit einem kleinen Code machen, wo du ein neues Feld automatisch erzeugst mit <Alter_Name>_1 zum Bsp, da die werte reinkopierst, dann das alte löscht, das neue anlegst und die werte zurück kopierst. Sowas schreibt man in Delphi doch ruck zuck.

Sind viele Abhängigkeiten da, dann bist Du angesch...en , weil die musst entweder händisch lösen oder eine generische Lösung schreiben, die das erst auflöst (trigger deaktivieren reicht glaube ich nicht), also Code der Objekte sichern, diese löschen und dann wieder einfügen.

Frag mal den Holger Klemt, vielleicht gibt es ja sowas in IBExpert oder er kann sowas einbauen, wäre ja ein cooles feature für Umsteiger von FB 2.x auf 3+

[DasWolf]

Zitat von mkinzler:

Dann wird dir nichts anderes übrig bleiben, als die Umstellung in mehreren Phasen durchzuführen.
-Einfügen neuer Spalten
-Kopie der Werte von alter auf neue Spalte 'J' -> True
(-Behandlung wenn FK andere Tabellen auf derartige Spalten)
-Löschen der alten Spalten
-Umbenennung der neuen Spalten

Dadurch gehen dann mal schnell und effektiv saubere Tabellenstrukturen flöten.

[mkinzler]

Zitat von DasWolf:

Zitat von mkinzler:

Dann wird dir nichts anderes übrig bleiben, als die Umstellung in mehreren Phasen durchzuführen.
-Einfügen neuer Spalten
-Kopie der Werte von alter auf neue Spalte 'J' -> True
(-Behandlung wenn FK andere Tabellen auf derartige Spalten)
-Löschen der alten Spalten
-Umbenennung der neuen Spalten

Dadurch gehen dann mal schnell und effektiv saubere Tabellenstrukturen flöten.

Warum?

[DasWolf]

Zitat von mkinzler:

Zitat von DasWolf:

Zitat von mkinzler:

Dann wird dir nichts anderes übrig bleiben, als die Umstellung in mehreren Phasen durchzuführen.
-Einfügen neuer Spalten
-Kopie der Werte von alter auf neue Spalte 'J' -> True
(-Behandlung wenn FK andere Tabellen auf derartige Spalten)
-Löschen der alten Spalten
-Umbenennung der neuen Spalten

Dadurch gehen dann mal schnell und effektiv saubere Tabellenstrukturen flöten.

Warum?

Ein kleines Beispiel ist anhand der beigefügten Bilder zu sehen (Vorher und Nachher).
Dort soll z.B. die Struktur so sein, dass die Felder Bearbeiter und BearbeitungsDatum immer hinten stehen.
Bei größeren Tabellen würde es dann noch unstrukturierter aussehen.

[mkinzler]

Die Reihenfolge der Felder kann man auch so anpassen, dass diese später wieder identisch ist.

[jobo]

Die Position der Felder in einer Tabelle ist in einem herkömmlichen Datenmodell nicht relevant und genauso undefiniert wie die Ausgabereihenfolge eines Selectstatements ohne Order by Clause.

Falls es fachliche oder ästhetische Vorgaben gibt für Feldpositionen, sind die durch geeignete Maßnahmen im GUI herzustellen.

Der Zugriff auf Tabellenspalten über ihre Position ist demnach auch nur vertretbar, wenn die Position durch eine explizite Select Clause definiert ist und damit unveränderlich. Ist das gegeben, so spielt wiederum die "natürliche" Position in der Tabelle keine Rolle.