[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Jan 2012
    Beiträge
    1.120

    Verschachtele /COPY Anweisung und embedded SQL

    Hallo,

    ich möchte 2 Copy Strecken verschachteln und bekomme im embedded SQL den Fehler SQL1003: Verschachtelte /COPY-Anweisungen nicht zulässig.

    Weiß jemand auf die Schnelle, ob man das beim CRTSQLRPGI einstellen kann? Bisher hatten wir die Verschachtelung einfach mit /INCLUDE anstatt /COPY gemacht. Dadurch hat der SQL Precompiler die 2. Copy Strecke ignoriert und es gab keinen Verschachtelungskonflikt. Jetzt brauche ich in einem Programm aber die 2. Copy Strecke und möchte, dass auch embedded SQL die Verschachtelung auflöst. Geht das?

    Dieter

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.236
    RPGPPOPT(*LVL1/*LVL2) sollte dies dann machen.
    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

  3. #3
    Registriert seit
    Jan 2012
    Beiträge
    1.120
    Ich habe es gerade ausprobiert. *LVL2 scheint für uns genau das richtige zu sein.

    Herzlichen Dank.

    Dieter

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.236
    Bedenke bei geschachtelten Copies/Includes Mehrfachcopies/Rekursionen per

    #ifndef MyCopyMbr
    #define MyCopyMbr
    :
    :
    #endif

    (oder so ähnlich) auszuschließen.
    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

  5. #5
    Registriert seit
    Jan 2012
    Beiträge
    1.120
    Vielen Dank für den Hinweis. Wir haben 2 "Ebenen" von Copystrecken. Zum einen die für die Serviceprogramm-Prototypes und zum anderen eine für Datenstrukturen. Die Serviceprogramm Copy-Strecken beinhalten alle auch die Datenstrukturen-Copystrecke. In der Datenstruktur Copy Strecke haben wir alles mit der if defined Direktive abgesichert. Z.B.:


    /if not defined(COPY__###_um_SwitchDS)
    D um_SwitchDS DS qualified template
    D Name 50A varying
    D Wert N
    /define COPY__###_um_SwitchDS
    /endif

    Scheint jedenfalls zu klappen.

    Nochmals Danke,
    Dieter

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.236
    Diese Direktiven sind am Besten grundsätzlich anzuwenden, also egal von welchem Typ der Copy ist.
    Der "/define" gehört direkt nach den "/if"!
    Warum?
    Da Copies nun mal gerne länger als eine Seite sind, fügt hier irgendjemand einen neuen /Copy vor dem "/define" ein und schon klappts nicht mehr mit der Absicherung, da der /Define zu spät kommt.
    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

  7. #7
    Registriert seit
    Jan 2012
    Beiträge
    1.120
    Also wäre folgendes besser?

    /if not defined(COPY__###_um_SwitchDS)
    /define COPY__###_um_SwitchDS
    D um_SwitchDS DS qualified template
    D Name 50A varying
    D Wert N
    /endif

  8. #8
    Registriert seit
    Nov 2007
    Beiträge
    371
    genau . also ich mache das persönlich immer so .

    /if not defined(COPY__###_um_SwitchDS)
    /define COPY__###_um_SwitchDS
    bla bla
    /endif

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.236
    Nun, das entspricht doch eher einer verständlichen Logik.
    Solange nun keiner einen "/undef" einbaut, bist du auf der sicheren Seite.

    Mittel "/if" lassen sich auch "konfigurierbare" Copies erstellen.
    Ich habe mehrere Gruppen von Funktionen in einem Copy.
    Allerdings benötige ich nicht alle.

    So kann ich in meiner Hauptquelle definieren:

    /define FktBlock1
    /define FktBlock2
    :
    /copy FktCopy

    Ähnlich wird es in z.B. C++ auch gemacht (Dieter wird jetzt mal wieder dagegen sprechen).

    Auch Versionen lassen sich so ggf. steuern.

    /if Defined(Version_2)
    d myCallProc pr extproc(MyCallProcV2)
    d Parm1
    d Parm2
    /else
    d myCallProc pr extproc(MyCallProc)
    d Parm1
    /endif

    Solange also keiner explizit auf V2 verweist, wird die alte Funktion verwendet.
    Dies vereinfacht die Kompilierung ins besonders bei längeren Copystrecken.

    Dieter wird auch hier was dagegen haben.
    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

  10. #10
    Registriert seit
    Jan 2012
    Beiträge
    1.120
    Vielen Dank.
    ich denke, ich werde unsere copy-Strecke entsprechend umbauen.
    Dieter

Similar Threads

  1. Artikel: Dauerhafte RPGUmwandlungsoptionen per/COPY
    By NEWSolutions Redaktion in forum NEWSolutions artikel
    Antworten: 0
    Letzter Beitrag: 05-12-13, 05:55
  2. runrmtcmd + copy per Batch
    By kuetemaj in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 05-02-03, 07:31
  3. EMBEDDED SQL in RPG
    By Ludger Muhmann in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 30-07-02, 09:49
  4. Embedded SQL
    By Stefan_R in forum IBM i Hauptforum
    Antworten: 0
    Letzter Beitrag: 12-10-01, 09:47
  5. Secure Copy
    By Marcus Scherz in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 26-07-01, 07:29

Berechtigungen

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