Aktivierungsgruppen verstanden?

[Fuerchau]

OVR's sind tatsächlich ein Problem, zumal diese gerne in einem CLP statt CLLE gemacht werden. Durch den Default ACTGRP wird das dann in der DFTACTGRP statt in der eigenen durchgeführt.
SHARE(*YES) musste ich für eine Anwendung explizit per OVRDBF wieder auf SHARE(*NO) ändern. Die Anwendung macht den SHARE(*YES), weil die Programmierer die Übersicht verloren hatten wann eine Datei nur I oder eben auch mit U geöffnet wurde.
Die SHARE-Option wirkt tatsächlich nicht auf SQL.

Ein OVRDBF wirkt allerdings auch auf SQL!
Hier scheitert dann manche "Sicherheitssoftware", die über die REGINF sich in die SQL-Überwachung reinhängt um SQL's zu analysieren, dabei aber das "Umleiten" per OVRDBF oder "CREATE ALIAS" vergessen.
Möchte man sich den OVRDBF in SQL sparen, so sind hier die Möglichkeiten eher eingeschränkt.
Entweder man arbeitet mit ALIAS-Tabellen oder mit dynamischem SQL, wobei hier Parameter wieder komplizierter sind.
Da ist ILERPG flexibler, da ich den Datei- und sogar den Teildateinamen in einer Variablen definieren kann.

Was den Druckoutput angeht, so gibt es hier nur geringe Alternativen.
Der OVRPRTF hat sich da i.W. durchgesetzt, da in einer Anwendung hier sehr viele Möglichkeiten definiert werden können (Output-Management) die sich anders nicht lösen lassen.
Im Gegensatz zur DB gibt es auch einige Formulareinstellungen die man anders nicht dynamisieren kann.
Hier sollte man halt generell mit OVRSCOPE(*JOB) arbeiten, da eine PRTF doch sehr programmspezifisch ist, ist das im Sinne der ACTGRP's eher unkritisch.

[BenderD]

Möchte man sich den OVRDBF in SQL sparen, so sind hier die Möglichkeiten eher eingeschränkt.
Entweder man arbeitet mit ALIAS-Tabellen oder mit dynamischem SQL, wobei hier Parameter wieder komplizierter sind.
Da ist ILERPG flexibler, da ich den Datei- und sogar den Teildateinamen in einer Variablen definieren kann.

... wer das braucht, ist Teil des Problems!!! Eine Datenbank ist eine Datenbank und normalerweise wird das beim connect erledigt, an welche Datenbank man denn nun verbinden will. Beim embedded SQL darf man nun mal nicht connecten, da muss man das ganz zu Beginn erledigen (SET SCHEMA bei naming *SQL, bzw. Einstellung des LIBL, wenn man denn unbedingt nicht nach SQL Standard arbeiten will).
Braucht man connects zu mehreren Datenbanken, verwendet man entweder CLI im Server Mode, oder in der technisch einfacheren Variante verschiedene ACTGRPS.

D*B

[Fuerchau]

Ich dachte da auch weniger an verschiedene Datenbanken (RDB's) sondern doch an verschiedene Tabellennamen in derselben DB mit jedoch identischem Aufbau.
Dies kommt in Anwendungen durchaus vor und wird bei RLA eben mit OVRDBF gelöst.

[BenderD]

... wofür soll das gut sein? Aber wenns denn Spass macht, gibt es da ja dynamic SQL.

Dieter

[Robi]

Moin,
in Umgebungen in denen es klare Programmierregeln gibt, eine brauchbare Doku gemacht wird und das Einhalten der Regeln auch weitestgehend durch Software geprüft wird, ist das alles nicht so schlimm!

Wenn im Betrieb immer wieder verschiedene Entwickler mal ein Projekt realisieren und danach durch andere ausgetauscht werden, sollten solche Konstrukte vermieden werden.
Nur, wie bewerkstelligt man das, wenn jeder sein eigener Gott und nur für sein Thema verantwortlich ist?

Meiner Erfahrung nach gibt es für fast alles was möglich ist auch eine 'einigermaßen' sinnvolle Anwendung.
Und natürlich eine 'einigermaßen' sinnvolle Alternative.