BC Migration: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „=Migration= Das Tool Migration dient dazu, Daten und Code auf eine andere Datenbank, auch auf ein anderes Datenbanksystem zu migrieren.“) |
|||
| (6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 2: | Zeile 2: | ||
Das Tool Migration dient dazu, Daten und Code auf eine andere Datenbank, auch auf ein anderes Datenbanksystem zu migrieren. | Das Tool Migration dient dazu, Daten und Code auf eine andere Datenbank, auch auf ein anderes Datenbanksystem zu migrieren. | ||
| + | |||
| + | Die Ziel-Datenbank muss mit der Auswahlliste links unten eingestellt werden. | ||
| + | |||
| + | ==SQL Select / SQL Exec== | ||
| + | |||
| + | Die Funktionalität dieser beiden Tabs gleicht der im Code-Formular: | ||
| + | |||
| + | *[[BC_SqlOpen|Code - SQL Open / SQL Open 2]] | ||
| + | *[[BC_SqlExec|Code - SQL Exec]] | ||
| + | |||
| + | ==Data Migration== | ||
| + | |||
| + | Auf dem Tab ''Data Migration'' werden Inhalte von Tabellen migriert. | ||
| + | |||
| + | [[file:mig data migration.png|1100px|Data Migration]] | ||
| + | |||
| + | Die Daten auf der Quell-Datenbank werden mittels eines SQL-Statements ausgewählt, das oben in der Mitte eingegeben wird. Üblicherweise wird das Statement nicht eingegeben, sondern mit einem Doppelklick auf den Tabellenname in der Liste links oben generiert. Sollen die Daten weitere eingeschränkt werden, so wird das Statement dann modifiziert. | ||
| + | |||
| + | Wird ein Statement mit Spaltenliste gewünscht (zum Beispiel, weil nicht alle Spalten migriert werden sollen), so wird die Option ''Detailed'' gewählt. | ||
| + | |||
| + | Mit dem Button ''Investigate'' wird untersucht, bei welchen Datensätze Unterschiede auftreten. Ist die Spalte ''Mode'' leer, so sind die Datensätze auf Quell- und Ziel-Datenbank identisch. Steht dort ein U, so sind sie unterschiedlich und die Daten werden bei der Migration mit einem Update-Befehl geändert. Steht dort ein I, gibt es den Datensatz auf der Ziel-Datenbank derzeit noch nicht und er wird bei der Migration mit einem Insert-Statement eingefügt. | ||
| + | |||
| + | Möchte man einzelne Datensätze von der Migration ausschließen, so lässt sich das SQL-Statement entsprechend modifizieren. | ||
| + | |||
| + | Mit einem Klick auf den Button ''Transfer'' wird die Migration durchgeführt. Da anschließend die Daten noch mal abgeglichen werden, sollten dann alle U- und IEinträge in der Spalte ''Mode'' verschwunden sein. | ||
| + | |||
| + | ==All Data Migration== | ||
| + | |||
| + | Wenn man ein BAF-System neu aufsetzt, dann ist es recht lästig, die Daten Tabelle für Tabelle zu migrieren. Hier nutzt man besser ''All Data Migration''. | ||
| + | |||
| + | [[file:mig all.png|1000px|All Data Migration]] | ||
| + | |||
| + | Zunächst holt man sich mit ''Get Tables'' eine Liste aller Tabellen des Quell-Systems. Wenn die Option ''Ignore History Tables'' gewählt ist, werden diese nicht in die Liste aufgenommen - man möchte die meistens nicht mit migrieren, gerade bei einer "Erstfüllung" nicht. | ||
| + | |||
| + | Die Liste ist bearbeitbar, sollen einzelne Tabellen nicht migriert werden, dann werden deren Listeneintrag einfach gelöscht, soll die Reihenfolge geändert werden, so ändert man die Reihenfolge der Listeneinträge. Es ist damit auch möglich, die Migration auf die "restlichen" Tabellen zu beschränken, wenn die Vorgang wegen eines Fehlers abgebrochen ist. | ||
| + | |||
| + | Mit dem Button ''Execute'' startet man dann die Migration, im darunterliegenden Textfeld wird das Ergebnis protokolliert. | ||
| + | |||
| + | ==Code Migration== | ||
| + | |||
| + | Code wird in der Tabelle ''sys_commands'' gespeichert, wenn man diese migriert, hat man auch den kompletten Code migriert. | ||
| + | |||
| + | [[file:mig code.png|800px|Code Migration]] | ||
| + | |||
| + | Arbeitet man mit der Trias von DEV, TEST und PROD, dann ist es nicht immer klug, den kompletten Code stur zu migrieren. Zum einen hat man auf DEV auch den einen oder anderen Versuch, den man gar nicht auf TEST und schon gar nicht auf PROD haben möchte. | ||
| + | |||
| + | Zum anderen werden in der Praxis oft Änderungen direkt auf dem Produktivsystem durchgeführt, und diese Änderungen würde man verlieren, wenn man stur den Code von TEST übernähme. Von daher kann man bei ''Code Migration'' sich Kommando für Kommando ansehen, wo die Unterschiede zwischen dem Quell- und dem Zielsystem liegen, bei Bedarf zuvor Änderungen noch in das Quell-System übernehmen und erst dann den Code migrieren. | ||
Aktuelle Version vom 14. August 2021, 21:44 Uhr
Inhaltsverzeichnis
Migration
Das Tool Migration dient dazu, Daten und Code auf eine andere Datenbank, auch auf ein anderes Datenbanksystem zu migrieren.
Die Ziel-Datenbank muss mit der Auswahlliste links unten eingestellt werden.
SQL Select / SQL Exec
Die Funktionalität dieser beiden Tabs gleicht der im Code-Formular:
Data Migration
Auf dem Tab Data Migration werden Inhalte von Tabellen migriert.
Die Daten auf der Quell-Datenbank werden mittels eines SQL-Statements ausgewählt, das oben in der Mitte eingegeben wird. Üblicherweise wird das Statement nicht eingegeben, sondern mit einem Doppelklick auf den Tabellenname in der Liste links oben generiert. Sollen die Daten weitere eingeschränkt werden, so wird das Statement dann modifiziert.
Wird ein Statement mit Spaltenliste gewünscht (zum Beispiel, weil nicht alle Spalten migriert werden sollen), so wird die Option Detailed gewählt.
Mit dem Button Investigate wird untersucht, bei welchen Datensätze Unterschiede auftreten. Ist die Spalte Mode leer, so sind die Datensätze auf Quell- und Ziel-Datenbank identisch. Steht dort ein U, so sind sie unterschiedlich und die Daten werden bei der Migration mit einem Update-Befehl geändert. Steht dort ein I, gibt es den Datensatz auf der Ziel-Datenbank derzeit noch nicht und er wird bei der Migration mit einem Insert-Statement eingefügt.
Möchte man einzelne Datensätze von der Migration ausschließen, so lässt sich das SQL-Statement entsprechend modifizieren.
Mit einem Klick auf den Button Transfer wird die Migration durchgeführt. Da anschließend die Daten noch mal abgeglichen werden, sollten dann alle U- und IEinträge in der Spalte Mode verschwunden sein.
All Data Migration
Wenn man ein BAF-System neu aufsetzt, dann ist es recht lästig, die Daten Tabelle für Tabelle zu migrieren. Hier nutzt man besser All Data Migration.
Zunächst holt man sich mit Get Tables eine Liste aller Tabellen des Quell-Systems. Wenn die Option Ignore History Tables gewählt ist, werden diese nicht in die Liste aufgenommen - man möchte die meistens nicht mit migrieren, gerade bei einer "Erstfüllung" nicht.
Die Liste ist bearbeitbar, sollen einzelne Tabellen nicht migriert werden, dann werden deren Listeneintrag einfach gelöscht, soll die Reihenfolge geändert werden, so ändert man die Reihenfolge der Listeneinträge. Es ist damit auch möglich, die Migration auf die "restlichen" Tabellen zu beschränken, wenn die Vorgang wegen eines Fehlers abgebrochen ist.
Mit dem Button Execute startet man dann die Migration, im darunterliegenden Textfeld wird das Ergebnis protokolliert.
Code Migration
Code wird in der Tabelle sys_commands gespeichert, wenn man diese migriert, hat man auch den kompletten Code migriert.
Arbeitet man mit der Trias von DEV, TEST und PROD, dann ist es nicht immer klug, den kompletten Code stur zu migrieren. Zum einen hat man auf DEV auch den einen oder anderen Versuch, den man gar nicht auf TEST und schon gar nicht auf PROD haben möchte.
Zum anderen werden in der Praxis oft Änderungen direkt auf dem Produktivsystem durchgeführt, und diese Änderungen würde man verlieren, wenn man stur den Code von TEST übernähme. Von daher kann man bei Code Migration sich Kommando für Kommando ansehen, wo die Unterschiede zwischen dem Quell- und dem Zielsystem liegen, bei Bedarf zuvor Änderungen noch in das Quell-System übernehmen und erst dann den Code migrieren.
