SQL - logische Datei - Update auf falschem Satz

[rissling]

Hallo Forum,

seit der Umstellung unserer Maschiene von V5R4 auf V7R1 haben wir folgendes SQL-Problem:
Wir haben DDS-beschriebene Datenbanken mit logischen Dateien, die bestimmte Sätze auswählen, z.B.:
A K ARTNR
A S FINR VALUES(02)
A O ALL
Diese logischen Dateien werden im RPG mit Chain, Read usw. genutzt. Dies soll in Zukunft durch SQL abgelöst werden. Neuere Programme nutzen daher schon SQL mit Update, etc. Es sieht so aus, als ob SQL versucht, die logischen Dateien zu nutzen, obwohl diese nicht alle Sätze bereit halten:

UPDATE EANP SET PREIS = 0 WHERE FINR = 2 AND ARTNR = 100096
findet und updatet den richtigen Satz.

Ein danach ausgeführtes
UPDATE EANP SET PREIS = 0 WHERE FINR = 6 AND ARTNR = 100096
sagt zwar, dass es ein Update gemacht hat, aber der richtige Satz enthält noch den alten Wert.

Wir vermuten jetzt, dass der SQL-Optimizer die logische Datei von oben nutzt, in der gar nicht alle Sätze zu sehen sind. Daher wird wahrscheinlich der Satz aus der ersten Abfrage erneut geupdatet.

Leider sind die logischen Datei nötig, da von vielen Programmen genutzt (Aufwand zu groß). Ändern der SQL-Abfragen wäre einfacher, da weniger Programme. Oder kann man am SQL-Optimizer was drehen?

Habt Ihr eine Idee?

Gruß,
Frederik Rissling

[B.Hauser]

Wir vermuten jetzt, dass der SQL-Optimizer die logische Datei von oben nutzt, in der gar nicht alle Sätze zu sehen sind. Daher wird wahrscheinlich der Satz aus der ersten Abfrage erneut geupdatet.

Ich kann auch nur vermuten!

Deshalb, finde zuerst heraus, ob es so ist wie Du vermutest, d.h. führe einen STRDBG (ohne irgendwas) aus.
Führe anschließend den Update aus und prüfe im Joblog welcher Zugriffsweg verwendet wurde.

Im Joblog werden nach dem Debug alle SQL commands protokolliert, so dass Du auch finden solltest, ob und warum der Datensatz nicht geändert wurde.

... auf alle Fälle sollte keine DDS beschriebene logische Datei je in einem SQL-Statement verwendet werden. Wenn es um die Selects und Omits geht, lege notfalls eine SQL View für die Selektion an und verwende diese.

Kann es sein, dass unter Commit gearbeitet wird und anstatt die Änderung festzuschreiben ein Rollback ausgeführt wird.

Sollte es wirklich so sein, dass der Satz laut Joblog geändert wurde und die Daten immer noch unverändert sind, solltest Du IBM einen Bug melden.

Birgitta

[Fuerchau]

Nun, wie stellst du denn fest, ob der Update erfolgreich war ?
Der SQLCOD ist auch beim Update von 0 Sätzen nämlich 0, ggf. vielleicht noch 100.
In SQLERD3 steht die tatsächlich Anzahl der Sätze, die gefunden und geändert wurden.

[rissling]

Deshalb, finde zuerst heraus, ob es so ist wie Du vermutest, d.h.

Es ist so wie vermutet: die logische Datei wird erneut genutzt, obwohl sie für diese Abfrage gar nicht geeignet ist (Gefunden im Navigator per VisualExplain)

Nun, wie stellst du denn fest, ob der Update erfolgreich war ?

Wir haben das Problem einfach isoliert und probieren es interaktiv aus: Der Navigator oder auch im Greenscreen über strsql sagt einem Sql, wieviele Sätze geupdatet wurden.

Inzwischen sind wir der Lösung aber auf der Spur: Stichwort: QSYS/QAQQINI, IGNORE_DERIVED_INDEX ( http://newsolutions.de/forum-systemi...h-bloed-2.html )
Leider gibt es mehrere Kopieren der Datei (z.B. in der QUSRSYS) und wir wissen wder, welche wir modifizieren müssen, noch, wann die Änderung aktiv wird (IPL?!), aber wir suchen weiter. :-)

Problem ist, dass ich auf jeden Fall heute eine Lösung haben muss, da wir und schon viele Artikel an den Kassen gelöscht haben und morgen auch noch eine große Aktion fahren.

Vielen Dank für Eure Hilfe!

[B.Hauser]

Inzwischen sind wir der Lösung aber auf der Spur: Stichwort: QSYS/QAQQINI, IGNORE_DERIVED_INDEX ( http://newsolutions.de/forum-systemi...h-bloed-2.html )
Leider gibt es mehrere Kopieren der Datei (z.B. in der QUSRSYS) und wir wissen wder, welche wir modifizieren müssen, noch, wann die Änderung aktiv wird (IPL?!), aber wir suchen weiter. :-)

Im Prinzip kannst Du die QAQQINI aus der QSYS in jede beliebige Bibliothek kopieren (mit CRTDUPOBJ) und dort modifizieren. (Nicht in der QSYS ändern und die QAQQINI in der QUSRSYS wird vielleicht von Fremdsoftware oder anderen Programmen verwendet).

Die Zuordnung der QAQQINI erfolgt über den CL-Befehl CHGQRYA (Change Query Attribute)

CHGQRYA QRYOPTLIB(MyLib)

Diesen Befehl kannst Du in Dein (Start-)Programm einbinden und ausführen. Dann wird die QAQQINI in dieser Biblitohek genommen.

Ich bin mir allerdings nicht sicher, ob die Änderung der IGNORE_DERIVED_INDEX-Option irgendwas bewirkt.

Vielleicht noch ein kleiner Trick, vielleicht klappt's. Ändere vor dem Update die Bibliotheksliste, d.h. nimm die Datenbibliothek raus und gleich darauf wieder rein. In diesem Fall sollte nochmal ein FULL OPEN, also eine komplette Optimierung erfolgen und ein anderer Index verwendet werden (können).

Auf alle Fälle solltest Du einen Call bei der IBM aufmachen und den Fehler melden!

Birgitta

[rissling]

Ich habe eine total simple, wenn auch nicht schöne Lösung gefunden:
ich habe die betroffenen SQL-Abfragen um eine Bedingung erweitert, die immer zutrifft, also z.B. WHERE ... and NAME <> ' ', und dessen Feld NICHT im Schlüssel einer logischen Datei vorkommt. Das zwingt den SQL-Optimizer offensichtlich dazu, die logischen Dateien zu ignorieren!

Okay, sicherlich nicht die Endlösung,aber funktioniert erst mal! ;-) Den Call bei der IBM haben wir natürlich schon vor Stunden eröffnet, aber noch keine Info. Werde ich in den nächsten Tagen noch aktualisieren.

Vielen Dank für Eure Hilfe!

Gruß,
Frederik

[rissling]

Ach ja:

... auf alle Fälle sollte keine DDS beschriebene logische Datei je in einem SQL-Statement verwendet werden. Wenn es um die Selects und Omits geht, lege notfalls eine SQL View für die Selektion an und verwende diese.

Wir updaten mit SQL natürlich die physische Datei und nicht die logische. Die suchts sich der Optimizer selber. Leider geht kein View, da im RPG mit chain gearbeitet wird und das in ca. 100 Programmen...