Zitat Zitat von BenderD
Commit Verwendung macht eigentlich nur mit embedded SQL und Schichtentrennung Spass und dann wird immer Committed bevor die Steuerung aus der Datenbank-Zugriffs Schicht nach oben geht und das war's.
Das Problem, dass viele von uns wahrscheinlich haben, ist, dass wir mit gewachsenen Anwendungen und Datenbanken, natürlich DDS-beschrieben, kämpfen müssen. SQL hat erst in den letzten paar Releasen wirklich an Bedeutung gewonnen. Das Haupt-Problem, was viele nicht sehen wollen, ist i.d.R., dass sich in der Datenbank über die Jahre jede Menge "Müll" (Redundanzen, überflüssige Zugriffswege) angesammelt hat. Bevor man allerdings daran etwas dreht, überlegt man zuerst, ob die RPG-Programm in JAVA umgestrickt werden sollten, und wundert sich dann, dass die Performance noch bescheidener ist.

Dem Einsatz von Embedded SQL steht man noch eher skeptisch gegenüber. (Ich musste schon Programme von Embedded SQL auf RPG umstellen, obwohl die SQL-Variante nachweislich schneller war). Ausserdem ist embedded SQL ist nur auf den ersten Blick einfach! Man muss schon wissen was man tut, bzw. man muss jedes SQL-Statement analysieren, und kann dann, wenn man das ganze auf eine andere Maschine mit anderem Release und andere Datenkonstellation transferiert, ein böses Erwachen erleben.
Da ist es doch einfacher eine vorhandene logische Datei in den F-Bestimmungen zu definieren, da weiss man was man hat! (Das ist nicht unbedingt meine Meinung, aber eine allgemein sehr verbreitete)

Es ist allerdings nicht so einfach, zu behaupten, erst dann wenn man aus der Datenbank-Schicht kommt, den Commit zu setzen. Es ist z.B. unverantworlich, einen kompletten Auslagerungs-Lauf, mit hunderten von Aufträgen unter einem einzigen Commit laufen zu lassen. Da muss schon mehr differenziert werden.

Birgitta