i5 und SQL

[Fuerchau]

@Birgitta
Bei DDS-Dateien erfolgt in COBOL mit Native-IO auch keine Prüfung auf ungültige Inhalte!
Die Schrottdaten die ich geschrieben habe bekomme ich beim Lesen genauso zurück.

Bei SQL-Tables darf ich auch in COBOL keine ungültigen Daten schreiben, das ist korrekt.
Der Unterschied zwischen COBOL und RPG ist i.W. der, dass COBOL mit den originären Dateipuffern arbeitet, währen RPG zusätzliche Moves von/zum Puffer einbaut.

Betrachte ich nun die Validierungsebenen so erhalte ich in RPG mehr als in COBOL.
RPG Lesen:
Chain/Read in internen Puffer ohne Validierung
Übertragung in Programmvariablen mit Validierung
RPG Schreiben:
Übertragung Programmvariablen in Dateipuffer mit Validierung
WRITE/UPDATE in internen Puffer ohne Validierung

COBOL Lesen:
Read in internen Puffer ohne Validierung
Eine Übertragung in Programmvariablen erfolgt erst gar nicht
COBOL Schreiben:
Eine Übertragung aus Programmvariablen erfolgt erst gar nicht
Write aus internem Puffer ohne Validierung

Bei embedded SQL habe ich sowohl in RPG als auch in COBOL grundsätzlich eine automatische Validierung, da die SQL's ja in Call's und Moves aufgelöst werden.
D.h., dass der Precompiler zusätzliche Variablen entsprechend der SQL-Definition generiert und beim Select/Fetch aus diesen in die Hostvariablen überträgt und eben beim Insert/Update aus den Host- wieder in die automatischen Variablen.
Neben der Validierung durch SQL selber erfolgt ja auch bei diesen Moves quasi schon eine Validierung, die eben durch die SQL-Schicht noch mal durchgeführt wird.

(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).

Es gibt bei COBOL mit SQL keinen Geschwindigkeitsvorteil mehr gegenüber RPG mit SQL, da ja nun in beiden Fällen mit zusätzlichen Moves gearbeitet wird.

[B.Hauser]

@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

[Fuerchau]

Und warum bekomme ich den geschrieben Schrott denn beim Lesen wieder zurück ?
Wenn eine Prüfung erfolgen würde, müsste ich ja einen Fehler beim Read bekommen.
Die schrottigen Daten stehen aber im Puffer.
Was macht die Prüfung denn dann für einen Sinn ?