spooled_file_data vs cpysplf

[RobertMack]

"Ablösen" ist vielleicht nicht der beste Begriff, aber ich kenne so einige Projekte, wo im SQLRPGLE viel Logik mit SQL realisiert wurde. Und warum auch nicht?

Einfach nur die RLAs durch schickes SQL ersetzen zu wollen ergibt ja auch keinen Sinn.

Die wahren Vorteile kommen schließlich erst zutage wenn man verquaste Logiken, versteckt hinter seitenlangen Selects, Ifs und Elses sowie dutzenden Bezugszahlen, aus dem RPG in die Datenbank verlegt.

Damit wäre dann auch endlich vermeintlich unersetzliches Wissen aus den Köpfen der "Alten" gerettet ;- )

[Fuerchau]

Um meinen Senf auch noch loszuwerden:
Überführen in SQL ist ja nicht schlecht, sondern erfordert i.d.R. ebenso ein Redesign der Anwendung.
Nur einfach einen CVTRPGSRC oder Konvertieren in Free per RDI ist keine Designänderung.

Zu SQL gehört nämlich auf jeden Fall auch die Behandlung von Transaktionen, was wiederum Journalisierung voraussetzt.
Erst wenn SQL komplett eingeführt ist, kann man auch von SQL sprechen.
Andere DB's kennen das Thema "Ohne Journal und Transaktion" gar nicht.
Auch wenn viele das Transaktionskonzept in diesen DB's durch "Autocommit" bereits für gelöst halten.

Und sicherlich gibt es auch bei diesen Projekten die 3-Stufigkeit.
- Datenbank
- Geschäftslogik
- Frontend/Batch

Zu Geschäftslogik gehört eben, so viel wie nur irgend möglich in Services (SQL Prozuduren/Funktionen + ILE-Serviceprogramme, Web-Services, ...) zu packen, die dann vom Frontend verwendet werden können.
Damit kann man auch die Aufgaben sinnvoll an die beteiligten Entwickler je nach Fähigkeiten aufteilen (wenn man die Ressourcen denn auch hat).