Zitat Zitat von Fuerchau
@Birgitta
Aussage 3 verstehe ich nun überhaupt nicht mehr !
Prüfung beim Lesen und nicht beim Schreiben ?
Welchen Sinn sollte das denn machen, dann würde ich ja beim Schreiben ungültige Daten wegschreiben können (was nachweislich z.B. bei Datum-Typen nicht geht) ?!
Mach mal folgendes Beispiel:
1. Datei mit CRTPF und fester Satz-Länge.
2. In diese Datei füllst Du irgendwelche alphanumerischen Daten.
3. Erstelle eine DDS-beschriebene Datei mit einem (oder mehreren numerischen Feldern)
4. Kopiere Datei 1 mit CPYF und FMTOPT *NOCHK in die DDS beschriebene Datei.
5. Mit WRKF wirst Du feststellen, dass der (oder die) Datensätze anstandslos übernommen wurden.

6. Jetzt erstelle die gleiche physische Datei (mit den numerischen Feldern) mit CREATE TABLE.
7. Kopiere Datei1 in diese mit SQL erstellte Datei (wieder mit CPYF und FMTOPT*NOCHK),
8. Jetzt wirst Du feststellen, dass kein Datensatz mit ungültigen Daten in die Datei übernommen wurde.
9. Alternativ kannst Du auch das Joblog prüfen.

Das sind so kleine Unterschiede zwischen DDS und SQL beschriebenen Dateien, die aber bis zu 40% Performance-Steigerungen mit sich bringen können, da in einer herkömmlichen Anwendungen weit mehr Lese- als Schreib-Operationen erfolgen. Die sonstigen Prüfungen, auf die Du anspielst, werden z.B. von RPG druchgeführt.

Welchen Sinn das Ganze macht, und warum das so ist, kann ich nicht sagen. Der Grund dafür wird wohl sein, für alte (/36 oder noch älter) Anwendungen eine Prüfung der Daten beim Einlesen der Daten erfolgen musste um Dezimal-Datenfehler u.ä. zu vermeiden, während die andere Vorgehensweise im SQL-Standard definiert ist.

Wer gerne mehr darüber wissen möchte, findet in der iNN - eNews vom Juni einen aktuellen Artikel von Dan Cruikshank:
Performance Comparison of DDS-Defined Files and SQL-Defined Files

Birgitta