View Full Version : Duplizieren einer mit SQL generierten Tabelle
Hallo *ALL,
wie kann ich, eine mittels SQL generierten Tabelle, mit all ihren VIEW's und Integritätsbedingungen usw. am einfachsten duplizieren.
Ich benötige das um unseren autom. Deploymentprozess von der Test- auf das Produktionssystem um die SQL-basierende Tabellen zu erweitern.
Gruß
Jürgen
Moin Jürgen,
ich hab mir für diese Zwecke vor ewigen Zeiten ein eigenes Kommando "CPYLF" mit einer CL Routine als Command Processing Program geschrieben. Als Parameter geb ich ihm den qualifizierten Namen der Tabelle bzw. PF sowie den Namen der Ziellibrary/-collection mit, dann wird via DSPDBR eine temporäre Ausgabedatei aller Datenbankrelationen der Tabelle erzeugt und für jeden Eintrag ein CRTDUPOBJ ausgeführt.
Also insgesamt wirklich sehr einfach gelöst, funktioniert aber wunderprächtig. Habe mir nie Gedanken gemacht, ob das auch via SQL lösbar wäre, isses aber sehr wahrscheinlich auch.
Wenn Du magst kann ich dir gerne den Sourcecode für das CPYLF zukommen lassen.
Grüsse
Martin
... aus der Denke von SQL arbeitet man da mit Erstellungsskripten, die gleichzeitig als Dokumentation dienen.
DB2/400 seitig wird das dann meist als reine Textdateien, die man mit RUNSQLSTM abdüst umgesetzt.
D*B
Hallo *ALL,
wie kann ich, eine mittels SQL generierten Tabelle, mit all ihren VIEW's und Integritätsbedingungen usw. am einfachsten duplizieren.
Ich benötige das um unseren autom. Deploymentprozess von der Test- auf das Produktionssystem um die SQL-basierende Tabellen zu erweitern.
Gruß
Jürgen
andreaspr@aon.at
22-03-10, 07:05
hi,
mit CPYF kannst du zwar auch die tabellen und LFs kopieren, ich würde aber auch, wie bender schon sagte, auf die skripts zurückgreifen und diese per runsqlstm ausführen lassen.
beim CPYF befehl musst du auch aufpassen, dass die tabellen im journal eingetragen sind, wenn mit commit gearbeitet wird.
Unabhängig von SQL:
Wenn die Tabelle, Views und Indexe alle mit dem selben Prefix beginnen und in der selben Lib stehen, reicht ein CRTDUPOBJ mit generischen Namen.
Es werden alle Objekte exakt dupliziert sowie die Bezüge angepasst.
Einzig Trigger behalten ihren absoluten Aufruf, da die Lib bereits beim Erstellen des Triggers zugewiesen wird.
Aber wie die Vorredner schon sagen, Erstellungsroutinen sind da schon sicherer.
Unabhängig von SQL:
Wenn die Tabelle, Views und Indexe alle mit dem selben Prefix beginnen und in der selben Lib stehen, reicht ein CRTDUPOBJ mit generischen Namen.
Es werden alle Objekte exakt dupliziert sowie die Bezüge angepasst.
Einzig Trigger behalten ihren absoluten Aufruf, da die Lib bereits beim Erstellen des Triggers zugewiesen wird.
Aber wie die Vorredner schon sagen, Erstellungsroutinen sind da schon sicherer.
Ab V5R4 können bei dem CRTDUPOBJ folgende
Parameter gewählt werden:
Einschränkungen duplizieren . . CST *YES
Auslöser duplizieren . . . . . . TRG *YES