SQL0150 bei insert in Tabelle

[Martin82]

Hi,

wir haben auf unserer i5(V5R4) seit ein paar Tagen folgendes Phänomen. Bei einem insert in eine Tabelle mit 5 Feldern bricht das Statement sporadisch mit diesem Fehler ab:

SQL0150
Message Text:
View or logical file &1 in &2 read-only.
Cause Text:
Update, delete, or insert is not allowed. &1 in &2 can be used only for read operations. A view or logical file can be used only for read operations if one or more of the following conditions are true: v The view contains a DISTINCT keyword, GROUP BY clause, HAVING clause, or a column function in the outer-most subselect. v The view or logical file contains a join function. v The view contains a subquery that refers to the same table as the table of the outer-most subselect. A view of this type may be used for inserting rows. v All the columns of the view are expressions, scalar functions, constants, or special registers. v All the columns of the logical file are input only. v The select list of the view omits a column of the based on table that does not allow null values or default values. Inserting into the view is not allowed.
Recovery Text:
Change the statement to insert, delete, or update data into the base table of view &1. All columns of the table that do not allow null values or default values must


Es handelt sich hierbei aber um keine View oder logische Datei. Wir haben bereits versucht das Objekt selbst, aber auch alle abhängigen Objehte, neu zu erstellen. Ohne positivem Ergebnis.
Kann es sein dass hier irgendein temporärer erstellter Index den Fehler hervorruft? Das letzte IPL der Maschine liegt 2 Monate zurück.

Vielen Dank für eure Hilfe
Grüße
Martin82

[buppo]

Hallo,

hast Du schon mal die Berechtigungen des View und des aufrufenden Benutzers geprüft.
Möglicherweise ist das View auf 'read' beschränkt

[B.Hauser]

Hallo,

hast Du die Biblitoheksliste geprüft?

Gibt es vielleicht irgendwo eine View (oder logische Datei) mit genau dem gleichen Namen wie die physische Datei?

Gibt es irgendwelche Lock-Situationen, die die Datei einem Job exklusiv zuordnen?

Birgitta

[Martin82]

Hallo,

hast Du schon mal die Berechtigungen des View und des aufrufenden Benutzers geprüft.
Möglicherweise ist das View auf 'read' beschränkt

Es handelt sich ja um eine Tabelle. Das ist ja das komische. Die Berechtigungen hab ich kontrolliert, hab temporär sogar *public *all gesetzt. Ohne Erfolg.

Hallo,

hast Du die Biblitoheksliste geprüft?

Gibt es vielleicht irgendwo eine View (oder logische Datei) mit genau dem gleichen Namen wie die physische Datei?

Gibt es irgendwelche Lock-Situationen, die die Datei einem Job exklusiv zuordnen?

Birgitta

Der Zugriff erfolgt per JDBC mit einer direkten Angabe der Bibliothek: "insert into ess.spezialspulen values('2', current_date,2108,0,0)"
Lock-Situationen könnte es geben, aber wie kann ich dies am besten kontrollieren? Zum Zeitpunkt des Auftretens des Fehlers herrschen keine Locks mehr vor...

[Martin82]

Hi,

jetzt hab ich folgendes probiert. Ich habe auf diese Tabelle alle vorgeschlagenen Indexe gelöscht("Clear all advised Indexes"). Seit dem ist der Fehler nicht mehr aufgetreten.
Kann sich jemand vorstellen was hier schief läuft?

[B.Hauser]

Ich kann mir nicht vorstellen, dass das Problem mit den vorgeschlagenen Indices zusammenhängt.

Die empfohlenen Indices werden ab Release V5R4 in eine System-Tabelle SYSIXADV geschrieben, zur Kontrolle und Überarbeitung. Bei dieser Datei handelt es sich um eine echte Tabelle und keine View.

Nachdem Du die empfohlenen Indices gelöscht hast, wird die Datei wieder neu aufgebaut werden. D.h. jedesmal wenn der Optimizer einen Index vorschlägt erfolgt ein Eintrag in diese Tabelle. Um eine Locksituation zu erzeugen, müssten schon gleichzeitig sehr viele gleiche Indices avisiert werden, was eher unwahrscheinlich ist.

Vielleicht hättest Du vor dem Löschen prüfen sollen, ob für Dein Statement vielleicht ein Index vorgeschlagen wird und eventuell diesen anlegen sollen.

Ansonsten hat weder SQL noch der Optimizer irgendwas mit dieser Tabelle zu schaffen, da nur vorhandene Zugriffspfade verwendet werden können.

Birgitta

[Martin82]

Vielleicht hättest Du vor dem Löschen prüfen sollen, ob für Dein Statement vielleicht ein Index vorgeschlagen wird und eventuell diesen anlegen sollen.

Hi,

du meinst in der Joblog? Dort wurde bei der Ausführung, vor dem Auftreten des Fehlers, kein Index vorgeschlagen.
Die "Advised Index" die ich gelöscht habe, die hab ich schon noch bzw. einer wird mittlerweile wieder angezeigt. Könnte ihn anlegen, aber jetzt werde ich mal abwarten ob dieser Fehler mit der Zeit nochmal auftritt...

[Fuerchau]

Gabs da aus Versehen mal einen UNIQUE-Index ?
Dann gibts normalerweise auch eine andere Meldung.

Jetzt kommt es ggf. noch auf die Art des SQL-Befehls bzw. Cursor's selber an.

Ein Select, der einen Join enthält ist nur aus o.g. Gründen überhaupt als Update-Cursor geeignet, so dass ein "Update of current .." fehlschlägt.

Ggf. muss dieser mit "for update of Field1, field2, ..." ergänzt werden, da nur die Primärtabelle für Update erlaubt ist.

[TARASIK]

Hallo Martin,
ich denke da hilft Dir dieser Apar:
IBM - SE27150 - OSP-DB-MSGSQL0150-F/QSQDELET IN SQL TRIGGER PROGRAM 06/10/13 PTF PECHANGE

Das Ptf "SI25498" wurde ersetzt durch "SI28130".

[Martin82]

Hallo Martin,
ich denke da hilft Dir dieser Apar:
IBM - SE27150 - OSP-DB-MSGSQL0150-F/QSQDELET IN SQL TRIGGER PROGRAM 06/10/13 PTF PECHANGE

Das Ptf "SI25498" wurde ersetzt durch "SI28130".

Hi,

das scheint des Rätsels Lösung zu sein. Hab vielen Dank!