PHP SQL Anweisung

[DISCOME]

Guten Abend,

wir arbeiten nun langsam immer mehr mit PHP und SQL.
Nun habe ich ein kleines Problemchen bekommen.

ALTER TABLE TEST.ANWESENHEIT ADD COLUMN DATUM3 CHARACTER (9) 

Ich möchte also einfach eine Spalte hinzufügen... sollte ja gehen. Leider passiert nichts.

Es kommt eine Meldung:
Warning: odbc_exec() [function.odbc-exec]: SQL error: [IBM][iSeries Access ODBC-Treiber][DB2 UDB]SQL0951 - Objekt ANWESENHEIT in TEST nicht geändert., SQL state S1000 in SQLExecDirect in C:\xampp\htdocs\TEST\AS400\PPR_ASSEMBLY_ANWESENHEI T.php on line 75

Besagte LINE 75 ist aber über den NAVIGATOR gekommen.

Ist das eine Berechtigungssache oder geht das einfach nur nicht?

Ich danke für eure Unterstützung.
MfG Andreas

[DISCOME]

Okay habe wohl ein kleinen Syntax nicht richtig geschrieben... wenn ich jetzt einen Text als ADD COLUMN nehme geht es. Ich möchte aber ".$DATE1." als COLUMN haben. Es lässt mich aber nicht. Wegen der Zahl an sich denke ich ja. Was kann ich da machen?

[andreaspr@aon.at]

Hallo,

den ersten Beitrag habe ich (halbwegs) verstanden. Bei deinem zweiten blicke ich nicht durch.
*) wie kann eine Anweisung aus einem PHP-Skript (Line 75) aus dem Navigator kommen??
*) was für ein Text als ADD COLUMN?
*) wieso eine Spalte mit "." vorne und hinten benennen?
*) was für ein Problem soll mit welcher Zahl geben?

Lass dir mal die DB2-Fehlermeldung ausgeben. Damit siehst du eventuell mehr:

echo 'SQLSTATE=' . db2_stmt_error() . ' ' . db2_stmt_errormsg();

Hoffe das hilft dir weiter.

lg Andreas

[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