[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Sep 2003
    Beiträge
    221

    Dateiverwendung aus SQLRPGLE-Programmen

    Guten Morgen,

    hier mal wieder eine Frage aus Köln (die gestern kläglich im DFB-Pokal gescheitert sind).

    Wir haben ein selbstgechriebenes Tool, dass mit DSPPGMREF einen Datenkatalog erstellt. Damit kann man sehr schön analysieren wo welche Tabellen verwendet werden. Das war bisher immer sehr hilfreich.

    Nun sind wir aber dabei, einige Programme von RPGLE auf SQL umzustellen. Ist ja auch eine feine Sache. Leider gehen bei dieser Art die Informationen aus dem Programm verloren.

    Gibt es da Systemkataloge, wo diese Info steht ? Oder muß ich die Tabelle als Dummy in der F-Karte deklarieren ?

    Gruß

    Peter Kinne
    Peter Kinne
    EDV-Beratung
    www.kinne.de

  2. #2
    Registriert seit
    Jan 2001
    Beiträge
    340

    PRTSQLINF

    da die Informationen mit PRTSQLINF zugänglich sind, sollte es ein API geben, mit dem man das auflisten kann. Mir fällt spontan keins ein. Einfach mal den API Katalog durchsuchen.

    Gruss
    Rolf

  3. #3
    Registriert seit
    Sep 2003
    Beiträge
    221
    Hallo Rolf,

    vielen Dank für den Tipp. ich schaue mal nach und poste das Ergebnis für die Allgemeinheit.

    Peter
    Peter Kinne
    EDV-Beratung
    www.kinne.de

  4. #4
    Registriert seit
    Mar 2002
    Beiträge
    5.287
    Hallo,

    so einfach und so schwer ist das garnicht:
    - das mit dem PRTSQLINF geht so nicht, bei fully dynamic sql ist da z.B. Ende der Fahnenstange.
    - gutes Design wird mit Übersichtlichkeit belohnt: In einer gut modularisierten Anwendung geht man von der Datenbank aus. Dort definiert man die externen Sichten (=Views), die benötigt werdenund nur auf diese wird zugegriffen, aber beileibe nicht von jedem Programm aus.
    - In der Anwendung gibt es nun eine relativ schmale Datenbankzugriffsschicht, die die Datenbankzugriffe kapselt, inklusive dem Transaktions Handling. Die Businesslogik an sich bedient sich nun dieser Zugriffsschicht, um mit der Datenbank zu kommunizieren.

    Selbstredend braucht man nun QS (Qualitäts Sicherung), die dafür sorgt, dass sich jeder dran hält. Dies ist aber leicht zu prüfen, da direkte Datenbankzugriffe (sprich embedded SQL) die Ausnahme sind.

    mfg

    Dieter Bender

  5. #5
    Registriert seit
    Feb 2001
    Beiträge
    20.241
    Sinn und Zweck des DSPPGMREF war ja nun meistens zu Ermitteln, welche Programme bei einer Änderung denn nun alles umgewandelt werden müssen.

    Bei SQL-Anwendungen geht man ja auch eigentlich einen anderen Weg (aber wer kann sich den schon leisten).

    Sog. CASE-Tools verwalten sowohl die DB als auch die Anwendungsprogramme (Module) und das CASE-Tool weiß nun, welches Modul ggf. angepaßt werden muss.

    Um nun die Info's aus PRTSQLINF auszuwerten bedarf es schon mal eines guten Syntaxanalyzers, da ja der SQL-Befehl und nicht die darin enthaltenen Dateien aufgelistet werden.
    Bei der Komplexität eines Selects (Joins, WITH, from (select ...) as usw.) ist es schon sehr schwer die richtigen Dateien herauszufinden. IBM gibt da leider keine Hilfsmittel (API) an die Hand obwohl die SQL-Laufzeit dies eigentlich könnte.

    Und dann muss ich nun Dieter noch recht geben, dass nun mal dynamische SQL's nun mal gar nicht zu ermitteln sind.
    Und wenn dann noch das CLI verwendet wird, sieht man noch nicht mal ob überhaupt SQL verwendet wird.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  6. #6
    Registriert seit
    Mar 2002
    Beiträge
    5.287
    Hallo Baldur,

    <snip>
    - Sinn und Zweck des DSPPGMREF war ja nun meistens zu Ermitteln, welche Programme bei einer Änderung denn nun alles umgewandelt werden müssen.
    </snip>

    Ich bewundere den Mut, sowas wirklich zu machen, zumal das fast immer nur fast funktioniert, oder nicht wirklich, wie meine Tochter sagen würde.

    <snip>
    Bei SQL-Anwendungen geht man ja auch eigentlich einen anderen Weg (aber wer kann sich den schon leisten).
    </snip>

    Ich wundere mich immer, wer sich eine andere Vorgehensweise leisten kann? Casus Knacksus ist, dass man mit SQL nur auf V i e w s zugreift, das heisst, dass ich an Programmen bei Änderungen in der Datenbank nie was ändern muss, solange dieselben Views dargestellt werden können; und das heisst im praktischen Leben nie.
    Angefasst werden bei dieser Vorgehensweise nur sehr wenige Programme, die zum Beispiel zusätzliche Felder verwenden und dafür werden dann immer ILE Prozeduren in bestehende Datenzugriffs-Module hinzugefügt. Wichtig ist hier also, dass keine Parameter Schnittstellen geändert werden, weil das ja wieder (riskante) technische Umwandlungen erforderlich machen würde.

    mfg

    Dieter Bender

  7. #7
    Registriert seit
    Dec 2002
    Beiträge
    301
    Hallo zusammen,

    ich habe soeben bei einem Kunden auf einer Maschine mit V4R5M0
    und einer Maschine mit V5R2M0 den DSPPGMREF zu einem Programm aufgerufen, in dem embedded SQL verwendet wurde. Und ich bekomme auch die Dateien angezeigt, die in den SQL-Statements verwendet werden. Ehrlich gesagt verwirren mich die
    Beiträge ein wenig, da ich es auch nicht anders kannte.

    Frank

Similar Threads

  1. 16MB Grenze in C Programmen umgehen
    By schatte in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 04-10-06, 15:22
  2. sqlrpgle
    By guru30 in forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 22-02-06, 14:53
  3. SQLRPGLE
    By mk in forum NEWSboard Programmierung
    Antworten: 7
    Letzter Beitrag: 17-11-05, 09:48
  4. *zoned bei SQLRPGLE Programm
    By Stefan_Sk in forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 12-07-05, 13:04
  5. Feldverwendung in Programmen
    By peter.kinne in forum IBM i Hauptforum
    Antworten: 9
    Letzter Beitrag: 02-09-04, 13:21

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •