Fehler bei Verwendung von UNIQUE in Tabelle

[andreaspr@aon.at]

Hallo,

ich bin auf ein Problem gestoßen welches ich nicht ganz verstehe.

(Alles läuft derzeit ohne Commit und ohne Journal.)

Ich habe eine Tabelle SRC.
Die laufende Nummer ist der Primärschlüssel.
ObjektNr., SourceFile und SourceLib bilden einen Unique-Key.

Sätze kann ich hinzufügen, wenn es jedoch ums Löschen geht, bekommen ich IMMER eine Fehlermeldung (auch wenn die tabelle neu erstellt und leer ist).

Entferne ich den Unique-Key funktioniert alles super.

 CREATE TABLE SRC
   (SRCNR     INTEGER GENERATED BY DEFAULT AS IDENTITY,
    OBJNR     INTEGER      /* Objekt Zuordnung             */
              NOT NULL WITH DEFAULT,
    SRCF      CHAR (10)    /* Source-File (QRPGSRC, ...)   */
              NOT NULL WITH DEFAULT,
    SRCLIB    INTEGER      /* Zuordnung der Source-Lib     */
              NOT NULL WITH DEFAULT,
    SRCMBR    CHAR (10)    /* Source-File (QRPGSRC, ...)   */
              NOT NULL WITH DEFAULT,
    SRCTYP    CHAR (10)    /* Source-Typ (RPGLE, CLLE, ...)*/
              NOT NULL WITH DEFAULT,
    SRCDAT    DATE         /* AEnderungs-Datum vom Source  */
              NOT NULL WITH DEFAULT,
    CONSTRAINT SRC_PK
         PRIMARY KEY (SRCNR));

Hier werden die Fremdschlüssel und der Unique-Key erstellt.

 ALTER TABLE SRC
  ADD CONSTRAINT SRCOBJ_FK
      FOREIGN KEY (OBJNR)
  REFERENCES OBJ (OBJNR)
  ON DELETE CASCADE
  ON UPDATE RESTRICT;

 ALTER TABLE SRC
  ADD CONSTRAINT SRCLIB_FK
      FOREIGN KEY (SRCLIB)
  REFERENCES LIB (LIBNR)
  ON DELETE CASCADE
  ON UPDATE RESTRICT;

 ALTER TABLE SRC
	ADD CONSTRAINT SRC_UNIQUE
	UNIQUE (OBJNR, SRCF, SRCLIB);

Hier die Fehlermeldung:

strsql                                          
Teildatei SRC nicht in Journal *N aufgezeichnet.
SRC in MYLIB für Operation ungültig.

Nachricht . . . :   SRC in MYLIB für Operation ungültig.                
Ursache  . . . . :  Ursachencode ist 3. Ursachencodes:                      
    1 - SRC hat keine Teildateien.                                          
    2 - SRC wurde mit freiem Speicherplatz gesichert.                       
    3 - SRC nicht im Journal aufgezeichnet, keine Berechtigung für Journal  
  oder der Journalstatus ist *STANDBY. Dateien mit                          
  RI-Integritätsbedingungsaktion CASCADE, SET NULL od. SET DEFAULT müssen im
  selben Journal aufgezeichnet werden.

Ist bei der Verwendung eines Unique-Keys ein Journal Pflicht?

Danke für jeden Denkanstoß.
lg

[andreaspr@aon.at]

Ich glaube das Problem gefunden zu haben.
Scheinbar benötige ich für eine Relationale Datenbank auf jeden Fall ein Journal.
Mit Journal habe ich keine Probleme mehr.
Vielleicht verwendet die Datenbank innerhalb der SQL-APIs Commitment-Control? Zumindest sieht es so aus.

[BenderD]

ON DELETE CASCADE

3 - SRC nicht im Journal aufgezeichnet, keine Berechtigung für Journal
oder der Journalstatus ist *STANDBY. Dateien mit
RI-Integritätsbedingungsaktion CASCADE, SET NULL od. SET DEFAULT müssen im
selben Journal aufgezeichnet werden.lg

ohne Kommentar
D*B

[Fuerchau]

Nun ja, die Fehlermeldung müsste dahingehend ergänzt werden:

Bei Integritätsbedingungen muss überhaupt ein Journal angelegt werden.

[BenderD]

... das stimmt so nicht, die Fehlermeldung ist klar und eindeutig, referential Constraint mit Cascade erfordert Journalisierung (mit restrict oder no action keineswegs), was einleuchtend ist.

D*B

Nun ja, die Fehlermeldung müsste dahingehend ergänzt werden:

Bei Integritätsbedingungen muss überhaupt ein Journal angelegt werden.

[andreaspr@aon.at]

... das stimmt so nicht, die Fehlermeldung ist klar und eindeutig, referential Constraint mit Cascade erfordert Journalisierung (mit restrict oder no action keineswegs), was einleuchtend ist.

... das stimmt so auch nicht, ich hatte alle 3 Varianten probiert, CASCADE, RESTRICT und NO ACTION.
Bei beiden der gleiche Fehler.

Ich vermute dass der Grund warum es beim Entfernen des Unique-Keys funktionierte, war weil der iSeries Nav auch den Fremdschlüssel der Tabelle SRCMBR entfernte dessen Feld auf diesen Unique-Key verbunden war.

Somit schaut es für mich so aus als ob ein Journal grundsätzlich notwendig ist (zumindest sobald ich Datensätze löschen möchte).

[BenderD]

... ein Blick in die Doku ist manchmal hilfreich! Die Lage ist eindeutig und alles andere unvollständig beobachtet oder ein Defekt Problem.
D*B

... das stimmt so auch nicht, ich hatte alle 3 Varianten probiert, CASCADE, RESTRICT und NO ACTION.
Bei beiden der gleiche Fehler.

Ich vermute dass der Grund warum es beim Entfernen des Unique-Keys funktionierte, war weil der iSeries Nav auch den Fremdschlüssel der Tabelle SRCMBR entfernte dessen Feld auf diesen Unique-Key verbunden war.

Somit schaut es für mich so aus als ob ein Journal grundsätzlich notwendig ist (zumindest sobald ich Datensätze löschen möchte).

[Fuerchau]

Da muss ich Dieter zustimmen.
"Nicht im selben Journal" ist auch korrekt, wenn kein Journal angegeben ist.

[andreaspr@aon.at]

"Nicht im selben Journal" ist auch korrekt, wenn kein Journal angegeben ist.

Verstehe gerade nicht was du damit meinst.

Ich habe am nächsten Tag das ganze noch mal mit ON DELETE NO ACTION getestet und plötzlich siehe da, geht es auch ohne Journal.
Was mich allerdings seeeeeehr gewundert hat, dass es beim ersten mal nicht funktionierte. Trotz commit=*none und ab und neu anmelden. Speziel weil ja auch NO ACTION der Default war.

Ich habe dann in einem Redbook meine Vermutung bestätigt bekommen, dass bei Contraints (außer bei RESTRICT und NO ACTION), das System in manchen Situationen automatisch Commitment Control verwendet, falls dies vom Programm selbst nicht eingeschaltet ist.

Ich verstehe nur nicht warum es mit NO ACTION nicht von Anfang an funktionierte.
Hat sich nun mit dem SQL SCHEMA erledigt.
Und dazugelernt hab ich auch wieder was

[BenderD]

Ich habe am nächsten Tag das ganze noch mal mit ON DELETE NO ACTION getestet und plötzlich siehe da, geht es auch ohne Journal.

... da gibt es nur zwei Möglichkeiten:
- das Problem sitzt meistens vor dem Bildschirm
oder
- ihr habt eine der ganz seltenen Maschinen erwischt, wo das nur jeden zweiten Tag funktioniert, dann muss man sich am besten aufschreiben, ob das an geraden oder ungeraden Tagen funzt

D*B