[NEWSboard IBMi Forum]
Seite 2 von 5 Erste 1 2 3 ... Letzte
  1. #13
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Wenn wir immer noch beim gleichen Problem sind und der andere Benutzer weiterhin den folgenden Fehler bekommt:
    1 -- Das externe Programm oder Serviceprogramm hat SQLSTATE 42926
    zurückgegeben. Die vom Programm zurückgegebene Textnachricht ist: LOB- und XML-Lokatoren sind mit COMMIT(*NONE) nicht zulässig.

    ... liegt es daran, dass in der Umgebung des Benutzers nicht unter Commitment Control gearbeitet wird.

    Versuch doch einfach mal am Ende des INSERT Statements WITH CS hinzuzufügen.
    Dann sollte das Insert Statement auch bei dem anderen Benutzer unter Commimtent Control ausgeführt werden, auch dann wenn in dieser Umgebung ohne Commitment Control gearbeitet wird.

    Da das INSERT-Statement bei Dir funktioniert, gehe ich davon aus, dass die Tabelle in einem Journal hinterlegt ist.

    Für die Verarbeitung in RPG würde ich für einen "kleinen" CLOB (65535 Zeichen) eine CLOB-Variable definieren und dann die Daten mit einem SELECT ... INTO, SET oder VALUES(...) INTO in diese CLOB-Variable ausgeben.
    Code:
    DCL-S  CLOBVariableName  SQLTYPE(CLOB: LängederCLOBVariablen)
    Die CLOB-Variable wird vom SQL-Precompiler in eine Datenstruktur konvertiert, mit den folgenden Unter-Feldern:
    CLOBVariableName_LEN UNS(10) => Datenlänge
    CLOBVariableName_DATA (CHAR (LängeDerClobVariablen)) => Daten

    Mit dem CLOBVariableName_DATA-Unter-Feld kann man in RPG ganz normal arbeiten und u.a. die Daten als Parameter an die nächste Prozedur durchreichen.

    Was vielleicht noch zu bedenken wäre. Bei dem Datentypen XML handelt es sich um keinen String, sondern um eine interne Representation des XML.
    Wenn Du das XML als Text (bzw. in RPG als CLOB) brauchst, musst Du das XML zunächst mit XMLSERIALIZE konvertieren.
    Wenn Du das XML, so wie es ist in RPG übernehmen willst musst Du die Variable mit dem Datentypen XML_CLOB (und Länge) definieren. Auch hier wird eine Datenstruktur mit den beiden Unterfeldern _LEN und _DATA gebildet ... und _DATA wann mit RPG verarbeitet werden.

    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

  2. #14
    Registriert seit
    Jan 2021
    Beiträge
    26
    wir arbeiten ja nicht unter commit , dass ist ja was wir nicht verstehen ...
    ist im RPG , die verwendung und nutzung von CLOBs zwingend mit comit verbunden ? gilt dies auch für das direkte SQL ?
    habs mit With CS probiert und funktioniert nicht , die Tabelle wird nicht journalisiert , zur Info ...

  3. #15
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Wir die Doku schon sagt, LOB's (CLOB/BLOB) setzen Commit-Control voraus. Beim Insert in die Tabelle muss diese journalisiert werden.
    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

  4. #16
    Registriert seit
    Jan 2021
    Beiträge
    26
    Dank eurer Hilfe und Unterstützung , vor allem auch von Britta , konnten wir zwischenzeitlich , die Daten aus dem IFS , qualifiziert in eine CLOB-Definierte File laden . Wir haben , nativ ( direkter SQL-Aufruf ) , auch von einem Fileserver , entsprechende XML-files laden und weiterverarbeiten können .
    In einem SQLRPG ( embedded ) , klappt der Aufruf , mit entsprechendem qualifiziertem VALUE auch ohne Probleme . siehe hier das Beispiel :
    exec sql insert into xx.xx values(get_clob_from_file('/home/geschi/test/clob/xxxxxxx.xml'))
    wenn die file aber auf einem fileserver liegt , dessen pfad und filebezeichnung über 100 stellen lang ist, muss der Pfad mit einer Variablen angegeben werden. den pfad mit der entsprechenden File, können wir zusammenknoten. nur wie fügen wir, den Pfad als variable mit variabler länge korrekt in den SQL-Aufruf ein?
    danke vorab für eure Hilfe.

  5. #17
    Registriert seit
    Jan 2021
    Beiträge
    26
    und noch eine weitere Frage , wie debugge ich das SQLRPG , um die SQL-Anweisung zu prüfen und schrittweise den Programmfortschritt zu prüfen . mit *source in den PRE-compiler , hatte ich lediglich die RPG-Anweisungen prüfen können und , da der aufruf interaktiv erfolgte , im LOG einige Infos ...

  6. #18
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Zu 1:
    dcl-s MyFileName varchar(256);
    exec sql insert into xx.xx values(get_clob_from_file(: MyFileName))

    zu 2:
    Ganz normal mit Debug(*source) und dann STRDBG oder über iseries Navigator:
    https://www.ibm.com/support/pages/us...ries-navigator
    Hier kann man dann mit F15 (glaube ich) auf verschiedene Sichten (Quelle, SQL, Liste) umschalten.
    Die SQL's werden in call 'QSQxxx' umgesetzt.
    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. #19
    Registriert seit
    Jan 2021
    Beiträge
    26
    zu1 , dies hatte ich probiert . Aber meine VAR hat Folgeleerstellen , gefüllt sind die ersten 112 stellen, der rest ist leer . beim ausführen erhalte ich einen Fehler zurück . wenn die VAR mit 112 länge definiert ist , klappt es .
    kann ich die länge im SQL mitgeben ?

  8. #20
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Entferne doch einfach die (evtl.) führenden und folgenden *Blanks:
    Code:
    exec sql insert into xx.xx values(get_clob_from_file(Trim(: MyFileName)));
    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

  9. #21
    Registriert seit
    Jan 2021
    Beiträge
    26
    funktioniert .. klasse ..
    Super, vielen Dank ..

  10. #22
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Den SQL-trim kann man sich eben sparen wenn man varchar verwendet.
    Wenn allerdings das Quellfeld nicht varchar ist, kann man auch per

    MyFileName = %trim(MyPath) + '/' + %trim(MyName);

    verwenden.
    Es gibt halt viele Wege zu SQL;-).
    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

  11. #23
    Registriert seit
    Jan 2007
    Beiträge
    904
    Ich habe mir angewöhnt, "varchar" Felder IMMER initialisiert zu definieren und/oder zur Sicherheit vorgängig einen clear darauf zu setzen. Dann klappt es auch mit der Feldlänge.
    kf

  12. #24
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das nützt aber nichts bei einer Übertragung von Char in Varchar. Da werden die Blanks halt mitgeschleift.
    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

Similar Threads

  1. Mit dem Bagger durch die Eifel oder wie debugge ich eine SQL Prozedur
    By KingofKning in forum NEWSboard Programmierung
    Antworten: 8
    Letzter Beitrag: 04-11-19, 08:59
  2. mehrere Spoolfiles in eine Datei
    By programmer400 in forum NEWSboard Drucker
    Antworten: 7
    Letzter Beitrag: 26-07-17, 11:58
  3. Antworten: 10
    Letzter Beitrag: 14-12-16, 16:45
  4. verschiedene Jobs gleiche Datei, schreib / lese konflikt?
    By dibe in forum NEWSboard Programmierung
    Antworten: 20
    Letzter Beitrag: 25-02-16, 16:33
  5. Antworten: 3
    Letzter Beitrag: 20-12-13, 10:27

Berechtigungen

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