[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Nov 2011
    Beiträge
    86

    CHGPF nach ADD COLUMN (MQTs)

    Hallo Forum!

    Wir haben aus einer "normalen", mittels DDS generierten PF eine MQT gemacht. Dafür haben wir mittels Alter table und add column die entsprechenden Felder hinzugefügt. Das funktioniert alles wunderbar.

    Jetzt funktioniert, fast schon logisch, der CHGPF auf diese Datei im Hinblick auf das Hinzufügen neuer Felder in der DDS nicht mehr.
    In sofern logisch, als dass die DDS die SQL-Spalten nicht kennt.

    Gibt es da trotzdem einen "Trick"? Eventuell beim CHGPF die SQL-Spalten zu ignorieren?

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Nein, du musst ab nun alles mit Alter Table durchführen.
    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
    Aug 2001
    Beiträge
    2.869
    Warum konvertierst Du die DDS-Datei nicht in DDL?

    Mit der SQL-Funktion GENERATE_SQL oder mit dem Wizard in ACS generierst Du Dir das CREATE OR REPLACE TABLE-Statement. OR REPLACE ist wichtig!
    Wenn alles soweit in Ordnung ist, d.h. das SQL Skript keine Fehler aufweist, fügst Du Deine neuen SQL-Felder in das Skript ein.
    Wenn Du dann das Skript ausführst, wird die Datei automatisch erweitert.
    Ähnlich wie beim CHGPF musst Du Dich weder um die Daten, noch um die abhängigen Objekte (LF, Views, Indices, Trigger ...) kümmern.

    Übrigens bei der Konvertierung von DDS in DDL mittels CREATE OR REPLACE TABLE musst Du noch nichteinmal die Programme neu umwandeln, da sich das Format Level nicht ändert.

    Das CREATE OR REPLACE Statement kannst Du dann entweder im IFS oder in einer normalen Quellenteildatei abspeichern.
    Bei der nächsten Änderung, änderst Du anstatt des DDS das CREATE OR REPLACE Statement ab und führst den SQL Code mit RUNSQLSTM aus.

    ... was ich allerdings nicht verstehe wie Du eine MQT erstellen konntest.
    MQTs basieren auf einem SQL SELECT Statement bei dem man meines Wissens mit ALTER TABLE keine Spalten hinzufügen kann.
    ... oder meinst Du irgendwas anderes.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  4. #4
    Registriert seit
    Nov 2011
    Beiträge
    86
    Hallo!

    Vielen Dank für die beiden Antworten. Haben mir sehr geholfen. Ich werde es jetzt mit Hilfe einer Sourcefile umsetzen und dann den Befehl RUNSQLSTM ausführen.

    Eine Frage habe ich aber noch. Wenn ich in der SRCFILE ein create table mache, erstellt er die Tabelle in der Bibliothek QSYS. Gibt es eine Möglichkeit vorher die Bibliothek festzulegen?
    Eine Lösung wie create table LIB.TABLE möchte ich nicht, da in der SRCFILE noch andere Operationen anschließend mit der Datei gemacht werden und ich möchte nicht überall die LIB vorschreiben.

    @Birgitta: Ich habe einfach an eine bestehende PF mittels ALTER TABLE die entsprechenden Spalten für die MQT angehängt.

  5. #5
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Bist Du sicher, dass Deine Tabelle in der QSYS erstellt wird? Ist es nicht vielleicht die QGPL?

    Wenn Du die Tabelle in Deinem Skript unqualifiziert angegeben hast, kannst Du die Bibliothek im RUNSQLSTM und zwar über die Option DFTRDBCOL festlegen.

    Code:
    RUNSQLSTM SRCFILE(YOURLIB/YOURSRCF)      
              SRCMBR(YOURSRCMBR)         
              COMMIT(*NONE)             
              DATFMT(*ISO)              
              MARGINS(132)              
              DFTRDBCOL(YOURDATLIB)     
              DECMPT(*COMMA)            
              LANGID(DEU)
    Und vergiss auf alle Fälle nicht den OR REPLACE, ansonsten war's das mit Deinen Daten!

    Du hast keine MQT (Materialized Query Table) erstellt, sondern lediglich die Datei erweitert.

    MQT ist eine Tabelle, die auf einem Select-Statement beruht und aktuell mir REFRESH aktualisiert werden muss. MQTs eignen sich hervorragend für statistische Auswertungen, da in einer MQT mehrere Tabellen verknüpft werden können und außerdem Daten verdichtet werden können. Sobald IBM den automatischen Refresh realisiert hat, können MQTs vom Query-Optimizer wie normale Indexes verwendet werden. Aktuell ist die Verwendung durch den Query Optimizer beschränkt, da zwischen MQT und echten Daten eine Diskrepanz auftreten kann. Ein direkter Zugriff auf die MQT ist jedoch immer möglich.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  6. #6
    Registriert seit
    Nov 2011
    Beiträge
    86
    Hallo Birgitta,

    vielen Dank für die Antwort. Ja, ich habe da etwas durcheinander geworfen. Ich wollte eine Versionierung zur Datei Datei hinzufügen. Keine MQT. Und ja, die Datei wurde in die QGPL gestellt
    Jetzt aber, dank deinem Hinweis DFTRDBCOL, nicht mehr.

    Jetzt habe ich diesbezüglich noch eine letzte Frage. Wenn ich die Tabelle mit create or replace table erstellte, funktioniert das zwar, aber ich bekomme den Hinweis:
    "Tabelle XXX in YYYY erstellt, aber nicht im Journal aufgezeichnet."
    Wie bekomme ich die Tabelle jetzt noch ins Journal? Bei DDS und PFs funktioniert das ja "automatisch".

  7. #7
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Per Default werden DDS beschriebene Dateien NICHT im Journal aufgezeichnet. Da passiert überhaupt nichts automatisch!
    SQL dagegen versucht per Default eine Tabelle immer in einem Journal aufzuzeichnen.

    Wenn das Schema/Bibliothek in dem die Tabelle erzeugt wird mit SQL generiert wurde, enthält das Schema ein Journal mit dem Namen QSQJRN. SQL versucht beim Erstellen einer Tabelle diese in einem Journal mit dem Namen QSQJRN zu registrieren. Fehlt das Journal (weil die Bibliothek mit CRTLIB erstellt wurde) und weil auch der Datenbereich QDFTJRN (in dem das Journal hinterlegt werden könnte) in der Bibliothek nicht vorhanden ist, bekommst Du die Warnung, dass die Tabelle nicht registriert werden konnte.

    An dieser Stelle solltest Du Dich zunächst erkundigen, ob bei Euch Dateien überhaupt im Journal aufgezeichnet werden und wenn ja in welchem.

    Für die meisten Hochverfügbarkeitslösungen müssen die Tabellen in einem Journal registriert sein. Wenn mit Commitment-Steuerung gearbeitet wird, müssen die Tabellen ebenfalls im Journal registiert sein.
    Wenn bei Euch die Dateien nicht in einem Journal registriert werden, kannst Du die Meldung ignorieren.

    Sofern die Dateien in einem Journal aufgezeichnet werden musst Du die Datei einmalig registrieren. Entweder über den CL-Befehl STRJRNPF oder über den Wizard im ACS oder Client Access.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  8. #8
    Registriert seit
    Nov 2011
    Beiträge
    86
    Grundsätzlich sind unsere Dateien, bis auf wenige Ausnahmen, nicht im Journal.
    Das Problem ist, dass ich beim öffnen der Datei den Fehler CPF4328 bekommen. Ich bin jetzt erstmal, nach Recherchen, davon ausgegangen, dass es sich dabei um den fehlenden Journaleintrag handelt. Gibt es noch eine andere Idee? Commit * None ist beim kompilieren des Programms und auch beim runsqlstm angegeben.

    Vielleicht spielt es noch eine Rolle, dass ich nicht direkt auf die Tabelle zugreife, sondern auf eine LF aus einer DDS.

  9. #9
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Bei dem Fehler handelt es sich um einen RPG-Fehler und hat mit SQL nichts zu tun.
    Vermutlich ist die Tabelle (oder eine logische Datei auf die Tabelle) in den F-Bestimmungen für Update hinterlegt und zwar mit Schlüssel-Wort COMMIT.
    In diesem Fall mussdie Tabelle mit STRJRNPF im richtigen Journal registriert werden.

    Commit *NONE im Compile-Befehl CRTSQLRPGI hat lediglich Einfluss auf die (embedded) SQL Statements.
    ... und wenn bei einem SQL Insert, Update oder Delete ein Fehler auftaucht (unabhängig davon ob durch COMMIT oder nicht) bricht das Programm nicht ab, sondern gibt einen negativen SQLCODE oder einen SQL-Status dessen erste beiden Stellen weder 00 noch 01 noch 02 sind.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

Similar Threads

  1. Berechtigung CHGRPYLE für ALTER TABLE DROP COLUMN
    By Gutmann in forum NEWSboard Programmierung
    Antworten: 10
    Letzter Beitrag: 18-07-18, 18:18
  2. Probleme mit Identity Column in Table
    By Tonazzo in forum NEWSboard Programmierung
    Antworten: 22
    Letzter Beitrag: 09-03-16, 16:11
  3. ZPL Konvertierung nach PDF
    By msost in forum NEWSboard Server Software
    Antworten: 1
    Letzter Beitrag: 13-01-14, 10:03
  4. Keine Journalisierung nach RW nach V5R2
    By csupp in forum IBM i Hauptforum
    Antworten: 5
    Letzter Beitrag: 24-03-03, 17:40
  5. OCL-Konvertierung nach CL
    By Bleil in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 07-02-01, 14:10

Berechtigungen

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