DDS --> SQL

[BenderD]

...wenn man das Glück hat in einer Firma zu arbeiten, wo man alles auf der Grünen Wiese neu machen darf...

... in meiner Firma darf ich alles, ich bin Freelancer!

Ich habe häufig genug mit Firmen zu tun, die auf bewährter (man könnte auch ältlicher sagen) RPG Software hocken und damit nicht mehr recht weiter kommen. Oft werden dann komplette Subsysteme dazu genommen (nicht jeder kann oder will SAP einführen), die auf Windows oder Linux laufen und andere Datenbanken benutzen, oft MS SQL Server oder MySQL, manchmal Oracle oder was anderes. Das macht meist auch Sinn, sei es weil man fusioniert hat oder auch weil es kostengünstig ist und gut passt. Der Kontakt zu diesen Kunden kommt dann meist über ArdGate zustande, weil man nach Möglichkeiten sucht, die Subsysteme möglichst synchron an die RPG Anwendung anzukoppeln und Daten-mäßig zu vernetzen.

Ich bin seit Jahren in den Bereichen Schulung tätig und habe auch Projekte zum Übergang auf neue Technologien begleitet und sehe da gewisse Prioritäten auf diesem Weg, wobei es da keine Patentrezepte gibt und das auch nicht in einem Forum erschöpfend behandelt werden kann.

- Weiterentwicklung des Knowhows geht immer vor Aktionismus!
- Jeder Schritt muss für sich genommen einen feststellbaren Nutzen haben!
- Es muss eine klare, positiv formulierte Zieldefinition geben!
- In den Bereichen Datenbank und Kommunikationsprotokolle gibt es etablierte Standards!

D*B

[Lucky662]

Bei meiner Beschreibung geht es darum einen Weg zu finden die etablierte RPG-Anwendung zu restrukturieren. Dabei ist die Datenbank das erste, um wirkliche Neuerungen einführen zu können.
Ja, es müssen natürlich auch die „alten“ Programme restrukturiert werden, (Modular aufbauen) und alte Zöpfe sollten abgeschnitten werden (Objekte und Sourcen löschen). Sonst verliert man den Überblick.
Wenn man die Altanwendung nichts mehr verändern möchte, sollte man natürlich auch nicht an der DB schrauben.
Aktionismus kommt immer nur zustande, wenn es keinen RPG-Fachmann mehr im Unternehmen gibt oder die fachliche Kompetenz bei dem RPG-Fachmann fehlt, und die Firmen neue Wege benötigen.
Dann werden andere Wege beschritten und das Chaos ist perfekt.
Auch für dieses Chaos gibt es in den Unternehmen einen feststellbaren Nutzen, zumindest in der Beschreibung. Zum Zeitpunkt der Entwicklung macht vieles noch Sinn und dann stellt man fest, dass ist eine Sackgasse für die zukünftige Entwicklung.
Das gilt übrigens auch für die fantastische neu eintwickelten Systeme. Programm-Messies (könnte man noch gebrauchen) vermüllen, mit der Zeit, auch eine klasse Anwendung.

[BenderD]

... das mit den Programm-Messies ist nur zu wahr. Programme werden mit jeder Änderung schlechter, wenn man keinen Restrukturierungsaufwand reinsteckt.

Wo wir uns unterscheiden ist, ob man mit der Datenbank anfängt.
Ich sehe das Hauptproblem in der engen Kopplung der Datenbank an die Anwendung durch RLA und favorisiere folgende Vorgehensweise:
1. Schritt:
- Neue Dateien nur per SQL erstellen
- View Layer für alle SQL Zugriffe (kein Zugriff auf PF!!!), auch auf die vorhandenen DDS PFs.
- SQL statt RLA bei jedem neuem Programm.
- Bei Programmänderung Redesign, minimal durch Auskoppelung Zugriffsroutinen (externe Aufrufe).
2. Schritt:
- Bei Änderung an rauszentralisierten Zugriffsroutinen Redesign Umstellung auf SQL Zugriffe
3. Schritt:
- Sobald eine DDS Datei frei von RLA Zugriffen ist, hat man alle Freiheitsgrade - auch für Änderungen am DB Design.
- ab hier kann man prüfen, wieweit DDS LFs Vorteile bringen (also in etwa das, was Du beschrieben hast).

D*B