Unterschiedliche Summen im Sql

[B.Hauser]

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

[BenderD]

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