Unterschiedliche Summen im Sql

[andreaspr@aon.at]

Starte einfach mal ein DB-Monitoring und schau dir den Zugriffsplan im Detail an.
Dort solltest du erkennen können ob irgendwo irgendwelche CASTs oder ähnliches gemacht wird, was dein Ergebnis verfälschen könnte.

Wenn du die Statements im Visual Explain nebeneinander Vergleichst bekommst du sicher einen Hinweis.

lg Andreas

[mk]

Hallo,

1. um andere Bibbliotheken auszuschliessen
(zum Test die Dateien qualifiziert lesen )

2. wie Baldur geschirieben hat
select felder
join mit Schlüsselfelder
where die variablen

3. MyIndicator
ist der in der SDS wirklich richtig positioniert ?

Gruß
Michael

[Pikachu]

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.

[Fuerchau]

Falsche Syntax!

select F1, f2, ...
from filea
inner join fileb on filea.key = fileb.key
where x1 = ...

[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