View Full Version : Unterschiedliche Summen im Sql
Die Definition deiner SDS enthält 2 Fehler:
SDjobnum muß 6stellig als "6s 0" definiert werden und MyIndikator muß als eigenständiges Feld (S) nach den Feldern der SDS definiert werden (da er nicht zur SDS gehört).
Siehe auch die Definition der SDS in ILE RPG (http://publib.boulder.ibm.com/infocenter/iadthelp/v7r1/index.jsp?topic=/com.ibm.etools.iseries.langref.doc/c0925086116.htm).
Falsche Syntax!
select F1, f2, ...
from filea
inner join fileb on filea.key = fileb.key
where x1 = ...
Falsche Syntax!
select F1, f2, ...
from filea
inner join fileb on filea.key = fileb.key
where x1 = ...
Die Syntax, die Tarkusch verwendet ist durchaus zulässig und liefert zumindest für inner joins verwendet werden das gleiche Ergebnis.
Unterschiedliche COMMIT-Angaben haben keinen Einfluss darauf, ob die Daten gelesen werden können oder nicht!
Ob die geänderten Daten (für alle Jobs!) gelesen werden können, oder nicht hängt vom Commitment-Level ab, das in dem Job verwendet wurde, in dem der Update erfolgte. Erfolgte der Update entweder ohne Commitment-Steuerung oder mit *CHG, können die geänderten Daten in allen Jobs (mit SQL oder native I/O) gelesen, jedoch nicht verändert werden bevor die Änderung festgeschrieben oder zurückgesetzt wurde. Dabei spielt es keine Rolle, ob in dem Job, in dem die Daten gelesen werden Commitment-Steuerung verwendet wird oder nicht.
Erfolgte der Update unter einem höheren Commitment Level, können die geänderten Daten auch in Jobs, in denen keine Commitment-Steuerung verwendet wurde nicht gelesen werden.
M.E. handelt es sich um ein "Bibliothekslisten"-Problem, d.h. entweder stimmt die Bibliotheksliste nicht überein, oder es werden unterschiedliche Namenskonventionen (System / SQL) verwendet oder es wurden unterschiedliche Datenbibliotheken über SET CURRENT SCHEMA gesetzt.
Birgitta
Birgitta
Die Syntax, die Tarkusch verwendet ist durchaus zulässig und liefert zumindest für inner joins verwendet werden das gleiche Ergebnis.
Unterschiedliche COMMIT-Angaben haben keinen Einfluss darauf, ob die Daten gelesen werden können oder nicht!
Ob die geänderten Daten (für alle Jobs!) gelesen werden können, oder nicht hängt vom Commitment-Level ab, das in dem Job verwendet wurde, in dem der Update erfolgte. Erfolgte der Update entweder ohne Commitment-Steuerung oder mit *CHG, können die geänderten Daten in allen Jobs (mit SQL oder native I/O) gelesen, jedoch nicht verändert werden bevor die Änderung festgeschrieben oder zurückgesetzt wurde. Dabei spielt es keine Rolle, ob in dem Job, in dem die Daten gelesen werden Commitment-Steuerung verwendet wird oder nicht.
Erfolgte der Update unter einem höheren Commitment Level, können die geänderten Daten auch in Jobs, in denen keine Commitment-Steuerung verwendet wurde nicht gelesen werden.
M.E. handelt es sich um ein "Bibliothekslisten"-Problem, d.h. entweder stimmt die Bibliotheksliste nicht überein, oder es werden unterschiedliche Namenskonventionen (System / SQL) verwendet oder es wurden unterschiedliche Datenbibliotheken über SET CURRENT SCHEMA gesetzt.
Birgitta
Birgitta
... damit sich da kein Quatsch in den Köpfen festsetzt:
Bei Daten, die sich in Änderung befinden, können Lesezugriffe mit unterschiedlichem Commit Level durchaus unterschiedliche Ergebnisse liefern.
Lesezugriffe mit read commited liefern nur konsistente Daten; je nach Implementierung werden Daten überlesen, oder es wird bis zum Ende der jeweiligen Transaktion gewartet. Läuft eine lesende Transaktion auf der AS/400 unter serialized, werden sogar andere Prozesse von updates auf die benutzten Tabellen völlig abgehalten (das ist im DB2 auf der AS/400 richtig schlecht implementiert!!!)
D*B