@Baldur:

Ich habe nie davon geredet, dass RPG oder Cobol oder (embedded) SQL beim Lesen oder Schreiben prüfen oder nicht prüfen!

Ich habe davon geredet, dass beim Schreiben in SQL Tabellen (direkt in den Tabellen) geprüft wird, ob gültige Daten ankommen oder nicht! Dabei ist es völlig unerheblich, wie dieses Schreiben erfolgt, d.h. selbst bei einem CPYF mit *NOCHK in eine SQL-Datei können keine ungültigen Werte in die Datei geschrieben werden.

Für jeden Move/Eval wird ja en MI-Befehl generiert und Dezimalbefehle prüfen generell auf gültige Feldinhalte, die ich aber mit IGNDECERR ausschalten kann
... und auch dann wirst Du keine ungültige gepackte numerische Daten in eine SQL Tabelle bekommen!

Beim Schreiben in DDS beschriebene Dateien erfolgt diese Prüfung nicht, d.h. mit einem CPYF und *NOCHK kann jeder Schrott in eine DDS beschriebene Datei kopiert werden.

Beim Lesen aus einer SQL-Tabelle erfolgt (innerhalb der Tabelle) keine Prüfung, während beim Lesen aus DDS beschriebenen Tabellen (bevor die Informationen bei RPG oder COBOL ankommen) geprüft wird, ob in den Feldern gültige Daten stehen. Was RPG und COBOL mit diesen Informationen machen, steht auf einem anderen Blatt!

Diese Prüfung beim Schreiben und beim Lesen erfolgt in der Tabelle bzw. in der physichen Datei und hat mit der Prüfung, die durch RPG, COBOL oder embedded oder interaktiven oder ODBC oder JDBC-Zugriff nichts aber auch überhaupt nichts zu tun!

.... und genau das steht auch in dem Artikel!!!

Wenn Du den Artikel genau gelesen hättest, hättest Du auch festgestellt, dass lediglich die physischen Dateien durch SQL-Tabellen und geschlüsselte logische Dateien durch SQL Indices ersetzt wurden (bzw. nach dem Erstellen der Indices die DDS beschriebenen logischen Dateien neu generiert wurden).

Das Programm, mit dem getestet wurde hat jeweils nur native I/O verwendet. Es erfolgte keine Konvertierung des Source-Codes in embedded SQL.

Birgitta