Phase 4 - SQL-Ausführung (GUI)
Einführung: Eine Beschreibung dieser Phase finden Sie im Abschnitt Phase 4 (Einführung). Siehe auch Abschnitt Icons in Mappings.
Aktivierung
Basis-Daten
Die Ausführung von Phase 4 können Sie in den Basis-Daten aktivieren mit Checkbox Phase 4 aktivieren.
Phase 2/Erweitert
Weitere Einstellungen (Checkboxen) für Phase 4 finden Sie in Phase 2/Erweitert.
SQL-Werte in Phase 4 trimmen |
Vor dem Schreiben von Werten in die Datenbank, können diese getrimmt werden. |
Bei SQL-Fehler mit nächstem Datenblatt fortfahren |
Siehe hierzu Abschnitt Bei SQL Fehler weitermachen. |
Beschreibung
Beim Mappen der Daten können parallel auch SQL-Statements erzeugt werden. Diese SQL-Statements werden nach Beendigung der Phase 3 ausgeführt, sofern Phase 4 freigeschaltet ist. Siehe vorheriger Abschnitt.
Dazu muss einem Zielstrukturfeld ein Spaltenname der Datenbank zugeordnet werden. Der Abschnitt Import der Struktur über Datenbank-Knoten beschreibt, wie die Struktur eines Datenbank-Knotens in der Zielstruktur des Mappings aus einer vorhandenen Datenbank-Tabelle erzeugt werden kann.
Zielstrukturfelder mit Spaltennamen müssen unterhalb eines Knotens liegen, dem eine Datenbank-Tabelle zugeordnet ist. Im Knoten wird neben dem Tabellennamen auch der Datenbank-Alias angegeben. Folglich können die Tabellen auch in unterschiedlichen Datenbanken liegen. Die Inhalte von Feldern unter Knoten mit Tabellennamen werden nicht in die Datenbank geschrieben, wenn im Feld kein Spaltenname eingetragen ist. Felder vom Datentyp BLOB werden als Byte-Array übergeben.
Alias und Tabellenname können auch aus Variablen gelesen werden. Ein Knoten wird innerhalb eines Jobs immer über den gleichen Alias in die gleiche Tabelle geschrieben. Eine Streuung auf unterschiedliche Datenbanken und Tabellen innerhalb eines Jobs ist also nicht möglich.
Eigenschaften Knoten
Die folgende Abbildung zeigt die SQL-Einstellungsmöglichkeiten eines Knotens in der Zielstruktur.
(1) Der Datenbank-Alias für diesen Knoten. Der Alias kann mittels einer Variable gesetzt werden. Der Wert muss jedoch innerhalb eines Jobs statisch sein. Nach Abschluss der Phase 3 wird der Wert ausgelesen und dann für alle Wiederholungen des Knotens in Phase 4 verwendet.
(2) Der Name der Tabelle, in die geschrieben werden soll oder das Kommando zum Aufruf einer Stored Procedure.
(3) Ist diese Eigenschaft auf Ja gestellt, wird der Tabelleninhalt zu Beginn der Phase 4 gelöscht. Hinweis: Dies gilt für alle auf Ja stehenden Knoten, aber nur, wenn Phase 4 aktiviert ist (siehe Abschnitt oben).
(4) Siehe dazu Abschnitt Zusätzliche SQL-Anweisung am Start einer Transaktion.
(5) Folgende Modi sind möglich. Siehe dazu auch die Abschnitte Eigenschaften Knoten (Zielstruktur) und Eigenschaften Felder (Zielstruktur).
insert |
Es wird versucht, den Datensatz zusätzlich zu den bereits bestehenden Datensätzen hinzuzufügen. Die Schlüssel-Eigenschaft von Feldern hat keine Relevanz. |
delete before insert |
Anhand der Schlüssel-Eigenschaft (erzeugt intern die WHERE-Bedingung) werden die treffenden Datensätze gesucht, gelöscht und anschließend der INSERT des aktuellen Datensatzes ausgeführt. |
try update before insert |
Anhand der Schlüssel-Eigenschaft (erzeugt intern die WHERE-Bedingung) wird entschieden, ob es in der Tabelle passende Datensätze gibt. Darauf wird das UPDATE ausgeführt. Wenn in der Tabelle noch kein passender Datensatz existierte, wird stattdessen ein INSERT mit den entsprechenden Werten ausgeführt. |
only update |
Es wird versucht, in den durch die Schlüssel-Eigenschaft (erzeugt intern die WHERE-Bedingung) identifizierten Datensätzen, die Werte der Nicht-Schlüssel-Felder neu zu setzen. Wenn kein Datensatz diesen Schlüsselwerten entspricht, hat das Statement keinen Effekt. Die Schlüsselfelder selbst werden beim UPDATE niemals verändert. |
only delete |
Es wird versucht, die durch die Schlüssel-Eigenschaft (erzeugt intern die WHERE-Bedingung) identifizierten Datensätzen aus der Tabelle zu löschen. Wenn kein Datensatz trifft, hat das Statement keinen Effekt. |
Stored Procedure |
Siehe Abschnitt Aufruf einer Stored Procedure. |
Hinweis: Im Normalfall werden die Felder, die in der Datenbank-Tabelle als Primary Key definiert sind, auch im entsprechenden Zielstrukturfeld die Schlüssel-Eigenschaft erhalten, aber das ist nicht zwingend. Beim Import eines Datenbank-Knotens wird die Schlüssel-Eigenschaft auch nicht automatisch gesetzt. Sie muss immer manuell gesetzt werden.
(6) Siehe dazu Abschnitt Transaktionssteuerung.
(7) Ist diese Checkbox gesetzt, wird der Knoten und seine Kinder am Ende der Phase 4 aus dem Zielbaum entfernt. Der Knoten wird auch entfernt, wenn keine SQL-Anweisungen an die Datenbank gesendet wurden. Diese Eigenschaft hat damit für einen Zielstruktur-Knoten dieselbe Wirkung, wie die Eigenschaft Berechnungsfeld bei einem Zielstruktur-Feld. Für die nachfolgenden Phase 5 und Phase 6 sieht der Zielbaum aus, als wenn der Knoten nicht vorhanden wäre. Im Mapping-Test können Sie solche Knoten aber dennoch sehen. Siehe auch Abschnitt "Beschneiden" des (Teil-)Zielbaums. In der Struktur wird das durch ein Datenbank-Icon dargestellt.
Eigenschaften Felder
Die folgende Abbildung zeigt die SQL-Einstellungsmöglichkeiten eines Feldes in der Zielstruktur.
(1) Der Name der Spalte in der Datenbank-Tabelle, die diesem Zielstrukturfeld zugeordnet ist.
(2) Gibt an, ob die Tabellenspalte einen Primary-Key in der Datenbank darstellt. Für UPDATE- und DELETE-Statements werden die Felder verwendet, die hier den Wert true gesetzt haben. Siehe auch (3).
(3) Ist diese Eigenschaft gesetzt, markieren Sie damit, dass das Feld in der Datenbank ein Autoincrement-Feld ist, d. h. die Datenbank verwaltet die Wertsetzung selbst, siehe auch (2). Felder dieser Art werden erst in Phase 4 während der SQL-Ausführung behandelt, mappen Sie also keine anderen Felder auf dieses Feld und verwenden Sie keine Funktionen darauf. Es gibt nur eine Möglichkeit in Phase 3 solche Felder zu benutzen. Wenn Sie im Mapping in einem nachfolgenden zweiten SQL-Knoten haben und dort den automatisch erzeugten Wert aus dem ersten SQL-Knoten als Fremdschlüssel verwenden wollen, können Sie auf das Fremdschlüsselfeld mit der copy-Funktion den Wert des AutoGenKey-Feldes kopieren. Aber auch das wird dann erst in Phase 4 ausgeführt. Hinweis: Möchten Sie das AutoGenKey-Konstrukt in mehreren Datenbankknoten verwenden, dann ist das möglich, allerdings nur, wenn die betroffenen Felder weder in der Zielstruktur, noch in der Datenbank den selben Namen haben, sonst erzeugt das einen Fehler.
(4) Siehe hierzu Abschnitt Nullwerte schreiben und Spalten überspringen.
Anmerkungen
Die Reihenfolge der Felder unter einem Datenbank-Knoten muss nicht unbedingt mit der Reihenfolge der Spalten der Tabelle übereinstimmen, weil die Felder über den eingetragenen SQL-Spaltennamen adressiert werden.
Wenn Felder als SQL-Schlüssel (2) gekennzeichnet sind, wird bei Updates mithilfe der Werte dieser Felder entschieden, welche Datensätze aktualisiert werden. Aktualisiert werden dann in den passenden Datensätzen nur die Werte der Spalten, deren zugeordnete Zielfelder nicht als SQL-Schlüssel gekennzeichnet sind.
Es gibt nur dann die Garantie, dass nur ein einziger Datensatz aktualisiert wird, wenn die als SQL-Schlüssel gekennzeichneten Felder auch wirklich einem UNIQUE KEY bzw. PRIMARY KEY der Tabelle entsprechen. In diesem Fall sollte auch für alle Schlüssel-Felder die Eigenschaft Pflichtfeld gesetzt werden.
Datenbankzugriff mit Funktionen
Alternativ könne Sie in Phase 3 mit Funktionen auf Datenbanken zugreifen. Siehe z. B. update (sql-stmt a, alias b, list c, ignore error d) (weitere Links finden Sie dort).