Fehlende Einträge in SYSCOLUMNS

[issvrcr]

Hallo,

ich habe ein Problem mit der Tabelle SYSCOLUMNS.
Ich möchte mittels SQLTALK eine Tabelle auf der AS400 erstellen, dies funktioniert auch, ich habe mittlerweile 1030 Tabellen in meiner Bibliothek so erstellt.
Jetzt habe ich einen Fall, ich setze den Befehl
CREATE TABLE L2001.ZEITTAET (MAN VARCHAR(5) NOT NULL,TAETINT VARCHAR(5) NOT NULL,SONDER VARCHAR(8),PROD VARCHAR(8),GEN VARCHAR(8),ANAB VARCHAR(8),MEHRAR VARCHAR(8),LA VARCHAR(3),LAMAN VARCHAR(5),LAAK VARCHAR(5),LAAB TIMESTAMP,TAETMAN VARCHAR(5));
ab, aber in der SYSCOLUMNS wird nicht hinterlegt und wenn ich diese Tabelle dann bearbeiten möchte z.B mit einem unload bekomme ich einen Memory Access Violation.

Kann mir da jemand weiterhelfen?
Liegt es eventuell an fehlenden PTFs?
AS400, Model 520, V5R2M0 CUM TL05263

Gruß und Dank im voraus
issvrcr

[Fuerchau]

Ist deine Lib L2001 eine Collection ?
Mit anderen Worten, hast du in L2001 eigene Jourale ?
Dann muss eigentlich ein CREATE TABLE auch committed werden.

Mir ist eigentlich kein Fall bekannt, dass in der SYSCOLUMNS was gefehlt hat.
Allerdings gibts da noch den "RCLSTG *DBXREF" der diese Informationen noch mal neu aufbaut.

[issvrcr]

Hallo Herr Fuerchau,

herzlichen Dank für die Antwort, nach weiteren Recherchen musste ich feststellen das 10% der Files beschädigt sind. Sie haben vollkommen recht das da nur noch der "RCLSTG" hilft.

Gruß
issvrcr

[issvrcr]

Hallo Forum,

nachdem wir einen Reclaim Starage durchgeführt haben sind weitere Probleme aufgetreten.
Ich beschreibe mal so kurz wie möglich.
Bei einem Update auf nsere Tabellen werden zuerst alle KEY's von der DB genommen (PK,FK und Indexdateien).
Dann werden einige Tabellen verändert und zum Schluss werden die KEY's wiede generiert.
Beim verändern der Tabellen trat nach dem RCLSTG der Fehler auf Constraint R_262 in check pending state.
Bei DSPCPCST kommt die Meldung, Integritätsbedingung kann für Tabelle nicht angezeigt werden.
Es wurden jetzt alle KEY's erneut gelöscht und die Datenbank mit einem Tool entladen.
Bei vielen Tabellen kam wieder diese Meldung "in check pending state".
Nachgeschaut mit DSPCPCST aber integritätsbedingung kann nicht angezeigt werden. Nachdem wir den Befehl RMVPFCST abgesetzt haben kam die Meldung Integritätsbedingung kann nicht entfernt werden konnten wir aber die Tabelle entladen.

Jetzt meine Frage:
Wie kann es zu solch einer Konstellation kommen????????????

Gruß und Danke issvrcr

[Fuerchau]

Da scheinen schon länger Fehler zu schlummern, die der RCLSTG nun aufgedeckt hat.

In solchen Fällen empfielt es sich dann (leider) seine Datenbank komplett Satzweise neu aufzubauen.

Ggf. hilft auch die letzte Datensicherung ?!

[issvrcr]

Hallo,

das ist mittlerweile geschehen mit viel Aufwand aber ich konnte nicht nachvollziehen warum die Integrität beschädigt war.
Vielleicht ist das eine Erklärung:
Einer meiner Kollegen hatte Probleme beim Rückspeichern von einer Sicherung mit nur geänderten Objekte, er hat dann die original Tabelle umbenannt und die Sicherung zurückgespielt. Ich vermute das der Constraint dann auf der umbenannten Tabelle lag.

Gruß
issvrvr

[Fuerchau]

Das ist korrekt !

Gerade beim Restore mit Constraints muss man Vorsicht walten lassen.
ALWOBJDIF hilft da auch nicht, da ja hier das selbe passiert wie manuell (umbenennen und neues Objekt).

Da Constraints im Wesentlichen verpointert werden bleibt die Beziehung immer bestehen, egal ob man das Objekt umbenennt oder verschiebt.

Im Restore-Fall muss man sich meist mit Hilfslib die Daten kopieren, was allerdings je nach Constraint schwierig werden kann (insbesonders Delete weiterreichen).
Ein CLRPFM wird ja auch abgelehnt, ein "delete from table" nicht. Dies führt dann dazu, dass abhängige Daten mit gelöscht werden und dann fehlen wohl wichtige.

Das Scenario kann man sich kaum ausmahlen.

Andere DB's (Oracle) sind da erheblich restriktiver.

[BenderD]

Hallo,

wieder mal ein typischer Fall, wo die wichtigen Details erst am Schluss benannt werden.
referential constraints werden beim restore nicht streng geprüft (weil der ja sonst nicht durchführbar wäre), die beteiligten Tabellen gehen dann auf check pending, bearbeiten kann man das dann mit WRKPFCST, wenn es sich nicht selber behebt. Rename von Datenbank Objekten ist natürlich keine gute Idee, genauso wie Zugriffe nach LIBL und OVRDBF, wer sowas macht, der erntet (irgendwann) Huddel.

mfg

Dieter Bender

Hallo,

das ist mittlerweile geschehen mit viel Aufwand aber ich konnte nicht nachvollziehen warum die Integrität beschädigt war.
Vielleicht ist das eine Erklärung:
Einer meiner Kollegen hatte Probleme beim Rückspeichern von einer Sicherung mit nur geänderten Objekte, er hat dann die original Tabelle umbenannt und die Sicherung zurückgespielt. Ich vermute das der Constraint dann auf der umbenannten Tabelle lag.

Gruß
issvrvr