PHP SQL Anweisung

[B.Hauser]

Das Problem liegt einfach darin, dass die Datei (oder ein abhängiges Objekt z.B. View) im gleichen Job bereits im Zugriff ist und deshalb nicht geändert werden kann.

(Zumindest sagt das die Detail-Information zum SQLCODE -951 bzw. SQL0951 aus)

Eine Spalte kann nur dann zu einer Tabelle hinzugefügt werden, wenn diese Tabelle (und auch die abhängigen Objekte wie Views) nirgends im Zugriff sind.

Die Zeile 75 kommt aus dem PHP-Skript und nicht durch den System i Navigator.

Birgitta

[DISCOME]

Richtig,

ich hatte die Verbindung noch nicht getrennt und wollte eine neue Spalte einfügen. Wohl doch zu viel auf einmal gewollt. :-)

Aber lieben dank für eure Unterstützung.

[Fuerchau]

Verbindungstrennung reicht ggf. nicht wenn ein ConnectionPool eingerichtet ist.
Dann wird die Verbindung nicht wirklich getrennt und nur in den Pool geschoben.
Beim Reconnect erhältst du also ggf. die selbe Verbindung dann wieder.

[andreaspr@aon.at]

Ich glaub das was du brauchst ist ein COMMIT um die Tabelle wieder freizugeben.
Ob eine Verbindung besteht oder nicht darf nichts damit zu tun haben ob eine Tabelle freigegeben frei ist. Das muss auch ohne eine Verbindung zu trennen (oder gar die kiste neu zu starten ) möglich sein!

lg Andreas

[BenderD]

... da würde ich eine SQL0910 erwarten...

Ich glaub das was du brauchst ist ein COMMIT um die Tabelle wieder freizugeben.
Ob eine Verbindung besteht oder nicht darf nichts damit zu tun haben ob eine Tabelle freigegeben frei ist. Das muss auch ohne eine Verbindung zu trennen (oder gar die kiste neu zu starten ) möglich sein!

lg Andreas

[Fuerchau]

Das Problem sind die ODP's, die auch bei Commit natürlich bestehen bleiben.
Ich kenne keine Möglichkeit, ODP's die von SQL automatisch offen gehalten werden explizit zu schließen.

Allerdings habe ich auch schon die Erfahrung gemacht, dass SQL die ODP's dann schließt wenn exclusive Locks auf der Tabelle benötigt wurden.
Dies erfolgte allerdings nur im selben Job der die ODP's offen hielt.

[B.Hauser]

Ich glaub das was du brauchst ist ein COMMIT um die Tabelle wieder freizugeben.
Ob eine Verbindung besteht oder nicht darf nichts damit zu tun haben ob eine Tabelle freigegeben frei ist. Das muss auch ohne eine Verbindung zu trennen (oder gar die kiste neu zu starten ) möglich sein!

lg Andreas

Commit bringt an dieser Stelle nicht viel, da vermutlich ein ODP (offener Datenpfad) auf die Datei vorhanden ist. ODPs werden durch einen Commit nicht gelöscht.

Wiederverwertbare ODPs bleiben so lange wie möglich offen. Ein Commit schließt allenfalls die Cursor, jedoch nicht die ODPs.

Was man versuchen könnte, sofern mit System Naming gearbeitet wird und der Zugriff auf die Tabelle unqualifiziert war, ist, die Dateibibliothek kurzfristig aus der Bibliotheksliste entfernen und wieder hinzufügen. Damit sollten die ODPs auf Tabellen in der Dateibibliothek geschlossen werden. Wird SQL Naming verwendet und der Zugriff erfolgte unqualifiziert, könnte eine Änderung des CURRENT SCHEMAs das Schließen der ODPs bewirken.

Birgitta

[andreaspr@aon.at]

Hallo zusammen.

Der ODP hat KEINE Auswirkungen auf fehlgeschlagene UPDATEs, DELETEs, INSERTs, ALTER TABLEs oder sonstiges!!

Es gibt einen Grund warum es nur mit umständlichen Einstellungen möglich ist den ODP zu löschen. Die Datenbank soll diesen selbst verwalten. Dem User soll es nicht interessieren ob ein ODP existiert oder nicht.

Wenn ein Job einen offenen Datenpfad zu einer tabelle hat, und ein anderer Job führt ein ALTER TABLE ADD COLUMN ... aus, dann löscht die Datenbank AUTOMATISCH!! den ODP vom ersten Job.
(Außer es gibt zu diesem Zeitpunkt einen offenen Cursor oder anders).

Also wenn eine Sperre vorhanden ist, dann aus einem anderen Grund.

lg Andreas