Schema kopieren

[becama]

Hi *all,

wir "kopieren" Schema1 in Schema2. Genauer: Schema1 wird in eine Savf gesichert und dann in Schema2 restored. Die Tabellen inkl. Dateninhalte werden sauber kopiert. Allerdings "zeigen" Trigger, Procedures und Functions noch auf Tabellen in Schema1. Wie kann man das ändern, ohne sie neu zu erstellen? Oder welche Möglichkeiten seht ihr noch? DANKE!!!

[Andreas_Prouza]

Ich schätze, dass hier überall qualifiziert via LIB drauf zugegriffen wird. Damit fängt das Problem an.
Verwendet man unqualifizierten Zugriff wird es über die LIBL gelöst.
Also in diesem Fall am Besten neu erstellen lassen.

[Fuerchau]

Da würde D*B eben sagen, *LIBL ist in SQL eher verpönt, da nicht Standard.
Ist ein SQL nicht qualifiziert und man verwendet die SQL-Notation, also Punkt statt Schrägstrich, dann wrd automatisch immer das current schema verwendet.

Mit den Funktionen/Prozeduren ist das nicht anders.
Bei der Erstellung werden diese in der QSYS2 registriert und können dann verwendet werden.
Hierbei gibts 2 Varianten:
Für SQL-geschriebene Funktionen/Prozeduren erstellt SQL ein Programmobjekt, dass die Definition selber enthält. Wird dieses Objekt per Save/Restore kopiert, registriert der Vorgang diese Objekte erneut mit dem entsprechenden Verweis. Daher sollte man diese eben auch in das Schema erstellen lassen, so dass diese mitgenommen werden können.
Für externe Funktionen/Prozeduren, also Verweise auf selbst geschriebene Programme, folgen diesem Verfahren nicht. Diese Funktionen/Prozeduren müssen mit der neuen Lib wieder neu erstellt bzw. registriert werden.

Man kann also auch durchaus dieselbe Funktionen/Prozeduren in unterschiedlichen Libs haben. Die Aufrufe und die Umgebung entscheiden, welche Variante dann aufgerufen wird.

Auch bei Triggern gilt dies. SQL-Trigger werden automatisch mitgenommen, Trigger per ADDPFTRG verweisen weiterhin auf die ursprünglichen Objekte.

[holgerscherer]

addendum: *LIBL kann gefährlich sein, wenn man nicht sicherstellt, daß sie jederzeit wie gewünscht gesetzt ist. Da hat IBM auch neulich lernen müssen, daß QSYS immer qualifiziert werden sollte.
Sauber wäre es in diesem Falle, die SQL-Sourcen zu verwenden und mit anderem Schema neu zu erstellen.

[B.Hauser]

Zunächst einmal kann man nicht mehr davon ausgehen, dass man anhand des Trennzeichens zwischen Biblothek und Objekt erkennen kann, ob man mit SQL oder System-Naming arbeitet.
Seit Release 7.1 TR 5 kann man nämlich bei System Naming sowohl den Punkt als auch den Schägstrich angeben.

Beim Erstellen von Views, Stored Procedures und User Defined Functions und Triggern werden auch bei unqualifiziertend Objekt-Angaben die eingebundenen Objekte ermittelt und die Bibliothek HART in den zu erstellenden Source Code integriert.
Verwendet man dabei System Naming werden die Objekte aus der aktuellen Bibliotheksliste ermittelt.
Verwendet man SQL Naming, werden die Dateien (phys. Dateien, SQL Tabellen, Views) aus dem Current Schema ermittelt. Alternativ kann man auch das Current Schema in einem integrierten SET OPTION Statement hinterlegen. Die SQL Routinen (Stored Procedures und User Defined Functions) werden aus dem Current Path ermittelt. Eine Art Bibliotheksliste, d.h. es können mehrere Bibliotheken aufgelsitet werden und diese werden in der angegebenen Reihenfolge durchsucht. Der Sonderwert *LIBL kann beim SQL Pfad angegeben werden. Auch der SQL PATH kann für das Erstellen und Ausführen über SET OPTION festgelegt werden.
Wird SQL Naming verwendet, kann nur eine Daten-Bibliothek unqualifizert angegeben werden. Dateien, Views, Aliases in anderen Bibliotheken müssen qualifiziert angegeben werden.
Um das festzustellen muss man lediglich mal einen kleinen Reverse Engineering (ACS - GENERATE SQL) um zu sehen wie der zur Erstellung des Objekts verwendete Source Code aussieht.

Sofern die Objekte neu erstellt werden sollen und entsprechende SQL Skripte mit RUNSQLSTM ausgeführt werden sollen, kann das Default Schema (für unqualifiziet angegebene phys. Dateien, Tabellen, Views) über die Option DFTRDBCOL angegebben werden.

Das gilt natürlich alles nur für statisches SQL! Dynamisches SQL wird erst zur Laufzeit ausgeführt, d.h. und dann die unqualifiziert angegebenen Objekte aus der Laufzeitumgebung (SQL Naming = Bibliotheksliste und System Naming = Current Schema, Current Path) ermittelt.

Langer Rede kurzer Sinn, was Holger auch schon gesagt hat!
Beim Kopieren/Umbenennen die SQL Scripte für die abhängigen Datenbanken-Objekte generieren oder sofern vorhanden entsprechend anpassen und danach ausführen.