Duplizieren einer mit SQL generierten Tabelle

[BenderD]

... 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]

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.

[Fuerchau]

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.

[mk]

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