View Full Version : ALTER TABLE mit DROP KEY für Tabelle auf DDS-Basis
Hallo Forum,
ist es möglich mit ALTER TABLE die Keys zu droppen, die ursprünglich mal mit DDS definiert wurden?
Ich habe schon alles mögliche versucht, aber es geht leider nicht.
Lt. Doku (V6R1) geht nur
alter table MYFILE
drop primary key
Ich habe schon
alter table MYFILE
drop primary key (myk1, myk2)
u.a. versucht.
Es gibt drei Schlüssel in der Tabelle via DDS, die Datei ist auf UNIQUE gesetzt.
Unabhängig von DDS-basiserten Tabellen:
Geht das überhaupt auf DB2?
Hintergrund:
Die Datei wurde ursprünglich mit DDS (mit UNIQUE und Schlüsseln) angelegt und über die Zeit um Felder und weitere Schlüssel via SQL erweitert.
Ein Ändern per DDS und CHGPF würde zwar die Schlüssel rausnehmen aber alles andere, was mit SQL nachgestrickt wurde, verwerfen.
Alex
... dann wäre es doch spätestens jetzt an der Zeit den Ist Zustand mit einem aktuellen Erstellungsskript zu konsolidieren (was man eigentlich bei jedem ALTER/CHGPF machen sollte)
D*B
Hallo Herr Bender,
ja, natürlich - prinzipiell gute Idee (weiß ich natürlich selbst - ist ja auch nicht alles auf meinem Mist gewachsen).
Generell wäre es schön zu wissen, was da so Sache ist mit ALTER TABLE und DROP KEYs bei DDS basierten Tabellen...
Alex
Kann es sein, das die Datei durch das entfernen des Keys nicht mehr unique ist?
Bekommst du einen Syntax - oder einen Laufzeit Fehler?
Robi
Ein CHGPF mit SOURCE ist auch möglich, wenn Indizes und Views auf die PF verweisen.
Es dürfen allerdings keine Felder entfernt oder dessen Ausprägung wesentlich geändert werden.
Dies habe ich schon mehrfach durchgeführt.
Die AS/400 erstellt eine temporäre datei, kopiert alle Daten, ändert alle Verweise aus DSPDBR.
Wenn das alles geklappt hat, wird das alte Objekt gekillt und das neue umbenannt.
Ich sehe also dein Problem nicht.
Die Datei wurde ursprünglich mit DDS (mit UNIQUE und Schlüsseln) angelegt und über die Zeit um Felder und weitere Schlüssel via SQL erweitert.
Ein Ändern per DDS und CHGPF würde zwar die Schlüssel rausnehmen aber alles andere, was mit SQL nachgestrickt wurde, verwerfen.
Guten Morgen Baldur ...
Der Fluch der bösen Tat:).
Ich wusste bisher nicht, dass man mit SQL an DDS-Tabellen Felder anhängen kann.
Dies gehörte (organisatorisch) auf jeden Fall verboten.
Ja, das sehe ich auch so.
Wer das bei uns macht bekommt einen körperlichen Verweis in Form einer Beule:D
Robi
Bei SQL wird ein Primary Key als Constraint intern angelegt und ist somit auch per SQL entfernbar.
Bei PF's mit Key ist dieser direkt Bestandteil der PF und somit von SQL nicht bearbeitbar.
Deshalb gehen auch die meisten Anwendungen so vor, dass die PF keinen Key hat und alle benötigten Schlüssel, also auch Unique's, per LF angehängt werden.
Dann stellt sich das Problem halt erst gar nicht.
Also nimm den Vorschlag von Dieter.
Die SQL-Syntax zum Neuerstellen der Tabelle und aller Abhängigkeiten kannst du dir ja per iSeries-Navigator generieren lassen, dann hast du auch eine änderbare Quelle.
Ansonsten
create table newtable as (select * from oldtable) with data
Anschließend umbenannen, LF's, Views usw. erstellen.
Am Besten in einer Arbeitslib, dann kann man die Objekte nachher gemeinsam verschieben.
Ich nehme mal an, dass du nur mit SQL auf die Tabelle gehst und LVLCHK nicht ausgeschaltet hast:).
... das ist doch alles der Weg von einem Hundehaufen in den nächsten. Statt hier das letzte bisschen Vernunft, den immerhin vorhandenen primary key zu eliminieren, sollte man hier die Chance nutzen, das Datenbankdesign an dieser Baustelle normalisieren und per Views das drüber zu bauen, was die Applikation benötigt.
D*B