[NEWSboard IBMi Forum]
Seite 3 von 3 Erste ... 2 3

Hybrid View

  1. #1
    Registriert seit
    Nov 2020
    Beiträge
    419
    Ich sehe es auch differenzierter als die Meisten.

    Klar, eine Funktion die z.B. eine Zahl in ein Datum umwandelt, soll keine Commit-Steuerung benötigen.
    Ich sehe aber auch kein Problem wenn eine Funktion für mehr verwendet wird.
    Wichtig ist nur, dass es entsprechend Definiert wird.

    Eine Funktion deren Name "TRANSFER_DATA_2_IFS" heißt, wird hoffentlich in keiner WHERE Bedingung eingebaut.

    Funktionen verwende ich, wenn ich lediglich einen Rückgabewerte erwarte und ich diese in SQL Statements verwenden möchte.
    Prozeduren verwende ich, wenn ich über die Parameter mehrere Rückgabewerte benötige.

    Wenn es aber aus technischer Sicht im IWS einfacher ist SQL Funktionen zu verwenden, warum soll man sich dann ein Beinbruch machen und komplexe Strukturen erschaffen, damit man am ende des Tages einen Heldentod sterben kann.

    Wartbarkeit & Sinnhaftigkeit steht über Religion.

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.376
    Zitat Zitat von dschroeder Beitrag anzeigen
    Wenn meine Funktion "writeBlob" heißt, würde ich im select schon erwarten, dass sie etwas schreibt. Ich bin natürlich vollkommen deiner Meinung, dass die Benamung der Funktionen und Methoden wichtig ist und klar ausdrücken muss, was eine Funktion tut.

    Commitment Control haben wir von 30 Jahre nicht mitbedacht. Das fällt uns jetzt bei einigen Aktionen auf die Füße, aber es lässt nicht mehr mit vertretbarem Aufwand verändern.

    Ich verstehe, dass du es kritisch siehst, wenn versucht wird, mit SQL zu programmieren. Aber ich habe ja bereits oben geschrieben, wie meine Anforderung ist. Es geht um große Blobs. Alle anderen Lösungen, die wir durchdacht haben (Webservices ohne IWS, stattdessen nativ in RPG implementieren oder andere Programmiersprachen (Python, Java, nodes.js) dazwischen zu legen), haben auch gewichtige Nachteile. Deshalb erscheint uns SQL sinnvoll.
    ... es gibt immer einen Weg, neue Programme transaktionssicher zu bauen. Noch wichtiger ist es, Krücken neu zu bauen, die einem den Weg noch weiter verbauen.
    Ansosnten bin ich bei Andreas: Daten per Parameter zu empfangen und in die Datenbank zu schreiben ist Alltagsgeschäft für SQL Prozeduren.

    D*B

    PS: Ob ich allerdings strategisch auf die morsche Bohle IWS setzen würde - was machst Du eigentlich, wenn IBM den schlachtet?
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  3. #3
    Registriert seit
    Jan 2012
    Beiträge
    1.215
    Zitat Zitat von BenderD Beitrag anzeigen
    ...
    PS: Ob ich allerdings strategisch auf die morsche Bohle IWS setzen würde - was machst Du eigentlich, wenn IBM den schlachtet?
    Berechtigte Frage.
    Zunächst gehe ich davon aus, dass wir das mit etwas Vorlaufzeit mitbekommen werden. Wir hätten dann genug Zeit, eine Schicht (wahrscheinlich in Java) zu bauen (nicht ich, sondern unsere Java-Developer), die das IWS ersetzt. Mit Springboot ist das auch kein Hexenwerk.

    Wir hatten auch schon Kontakt mit Andreas (Prouza). Er hatte da Ideen, so eine Schicht auch in Python oder ähnlichen Sprachen zu bauen.

    Ich denke, da gibt es mehrere Möglichkeiten.

Similar Threads

  1. Variable als Parameter für SUBSTR in SQL-Anweisung (UDF)
    By hartmuth in forum NEWSboard Programmierung
    Antworten: 2
    Letzter Beitrag: 24-07-14, 10:52
  2. RPGLE an einer Transaktion teilnehmen lassen?
    By Bratmaxxe in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 24-02-11, 08:37
  3. Erstellen einer UDF mit UNION
    By e_sichert in forum IBM i Hauptforum
    Antworten: 9
    Letzter Beitrag: 09-05-08, 13:25
  4. Probleme mit dem Aufruf einer UDF
    By e_sichert in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 08-05-08, 09:35
  5. SQL0332 beim SQL-Aufruf einer UDF(Java)
    By Ewald in forum NEWSboard Programmierung
    Antworten: 4
    Letzter Beitrag: 24-01-07, 14:38

Berechtigungen

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