UDF V6R1

[dschroeder]

Noch eine kleine Optimierung: Du willst ja eigentlich gar nicht wissen, wie viele Sätze in der Datei sind, sondern nur, ob es mehr als 0 sind. Deshalb würde ein "fetch first row only" verhindern, dass alle gezählt werden:
select count(*) into anzahl from dat020 fetch first row only;

[KingofKning]

Hallo,
werde ich morgen mal ausprobieren.

BTW. In der Tabelle sind hinterher Max. 200 Sätze, deswegen passt der Satz „Noch eine kleine Optimierung...“ ;-)

[B.Hauser]

Versuch mal bei dem CASE die SELECT-Anweisung in eine Klapper zu packen.

Birgitta

[KingofKning]

Hallo *all,

mir fehlt jetzt nur noch die Konvertierung von hex nach decimal. Finde es auf Anhieb nicht wie der cast aussehen muß. Weil ohne fällt das Teil ab 000A auf die Nase.

Wie kann man eigentlich solche UDFs debuggen?

Ansonsten sieht meine UDF so aus.

CREATE FUNCTION rptrade/zaehler /*11.10.19 10:51*/      
( DEBITOR dec(08) ) RETURNS                            
CHAR(04)                                                
LANGUAGE SQL MODIFIES SQL DATA ALLOW DEBUG MODE         
DISALLOW PARALLEL                                       
BEGIN                                                   
DECLARE RETURNVAL CHAR   (04) NOT NULL DEFAULT '0000' ; 
DECLARE i_zaehler decimal(04) DEFAULT 0;                
                                                       
 select d020werta into i_zaehler                       
        from dat020 where d020key = debitor;           
 if i_zaehler = 0 then                                 
    select d020werta into i_zaehler                    
           from dat020 order by d020werta desc         
                     fetch first row only;             
    set i_zaehler = i_zaehler + 1;                     
    insert into dat020 (d020key, d020werta)                     
           values(debitor, substr(hex(int(i_zaehler)), 5, 4));  
 end if;                                                        
 set returnval = substr(hex(int(i_zaehler)), 5, 4);             
 RETURN LTRIM(RETURNVAL);                                       
END

[Fuerchau]

Wie wäre es mit

select 'J' into :vorhanden from datei where exists (...)
Schließlich enthält der Exists implizit den Fetch first und ist für den Einzelsatzzugriff optimiert.

[BenderD]

Hallo *all,

mir fehlt jetzt nur noch die Konvertierung von hex nach decimal. Finde es auf Anhieb nicht wie der cast aussehen muß. Weil ohne fällt das Teil ab 000A auf die Nase.

Wie kann man eigentlich solche UDFs debuggen?

Ansonsten sieht meine UDF so aus.

CREATE FUNCTION rptrade/zaehler /*11.10.19 10:51*/      
( DEBITOR dec(08) ) RETURNS                            
CHAR(04)                                                
LANGUAGE SQL MODIFIES SQL DATA ALLOW DEBUG MODE         
DISALLOW PARALLEL                                       
BEGIN                                                   
DECLARE RETURNVAL CHAR   (04) NOT NULL DEFAULT '0000' ; 
DECLARE i_zaehler decimal(04) DEFAULT 0;                
                                                       
 select d020werta into i_zaehler                       
        from dat020 where d020key = debitor;           
 if i_zaehler = 0 then                                 
    select d020werta into i_zaehler                    
           from dat020 order by d020werta desc         
                     fetch first row only;             
    set i_zaehler = i_zaehler + 1;                     
    insert into dat020 (d020key, d020werta)                     
           values(debitor, substr(hex(int(i_zaehler)), 5, 4));  
 end if;                                                        
 set returnval = substr(hex(int(i_zaehler)), 5, 4);             
 RETURN LTRIM(RETURNVAL);                                       
END

wenn ich das richtig verstehe, dann schreibst du einen Satz mit '0001' in dem Huddelfeld in die Datei, wenn ein Satz mit einer 0 (mit oder ohne Hierarchie) schon drinsteht.
Im Returnwert gibst Du dann '0001' zurück.
In allen anderen Fällen (kein Satz gefunden, oder schon zwei drin, geht Deine Procedure in die Grütze.

Ist das so gewollt?

D*B

[KingofKning]

wenn ich das richtig verstehe, dann schreibst du einen Satz mit '0001' in dem Huddelfeld in die Datei, wenn ein Satz mit einer 0 (mit oder ohne Hierarchie) schon drinsteht.
Im Returnwert gibst Du dann '0001' zurück.
In allen anderen Fällen (kein Satz gefunden, oder schon zwei drin, geht Deine Procedure in die Grütze.

Ist das so gewollt?

D*B

Kann ich jetzt nicht so bestätigen

 Anfang auf Zeile . . .
 ....+....1....+....2..
    D020KEY   D020WERTA
          1     0001   
          2     0002   
          3     0003   
          4     0004   
          5     0005   
          6     0006   
          7     0007   
          8     0008   
          9     0009   
         10     000A   
 ********   Datenende

Vermutlich werde ich mir morgen eine HEX nach DEC Funktion selber schreiben. Habe ich das letzte mal im Informatikunterricht 1982 auf einem CBM 8032 gemacht.
Hätte nicht gedacht das ich das ein paar Tage später mal für ne AS/400 machen muß die die Funktion nicht kennt.

GG 4250

[Fuerchau]

Ich frage mich nun allen Ernstes, wozu du denn mit HEX=>Dec oder auch zurück nun arbeiten must.

Das SQL nun mal keine Strukturen kennt und schon gar nicht mit Überlagerungen kannst du in RPGLE durch Overlays von Char mit Int(3), Int(5), int(10) und int(20) Binär nach Dezimal und umgedreht erstellen. Die Hex-Wandlung in SQL ist dann nicht erforderlich.

[KingofKning]

Die Antwort ist simpel: Wir haben leider SAP im Einsatz, und da sind die Kundennummern 8stellig. Weiterhin haben wir unsere Software RP-Trade, und da sind die Kundennummern 5stellig (Preislisten).

Fällt Dir was auf ;-)
Richtig, das passt so nicht. Deswegen die Krücke HEX.
RPG habe ich als COBOL Programmierer nie gemocht und kann es auch nicht. Und da die Aufgabe ja mit SQL lösbar ist, warum nicht. Wobei es mich schon wundert warum man eine HEX-Funktion implementiert aber nicht das Gegenteil davon.

Aber noch ein paar Stunden, und die Aufgabe ist gelöst. Und wenn ich gemein bin, gebe ich das am Montag meinem Azubi......

Wobei mir jetzt beim Schreiben eingefallen ist das ich eigentlich ja nur eine fortlaufende Zahl benötige und noch nicht mal hex brauche. (Hex habe ich damals im COBOL Programm gemacht als die Kundenummer noch sechsstellig war und ich auf 5 Stellen mußte)
Man sieht, drüber diskutieren bringt häufig was.

GG 4250

[Fuerchau]

Aber 8-stellige Kunden geben doch 16-Hexstellen?
Mach doch einfach eine Mappingtabellen von 8 auf 5-Stellig, das funktioniert ebenso in beide Richtungen.

[BenderD]

Die Antwort ist simpel: Wir haben leider SAP im Einsatz, und da sind die Kundennummern 8stellig. Weiterhin haben wir unsere Software RP-Trade, und da sind die Kundennummern 5stellig (Preislisten).

Fällt Dir was auf ;-)
Richtig, das passt so nicht. Deswegen die Krücke HEX.
RPG habe ich als COBOL Programmierer nie gemocht und kann es auch nicht. Und da die Aufgabe ja mit SQL lösbar ist, warum nicht. Wobei es mich schon wundert warum man eine HEX-Funktion implementiert aber nicht das Gegenteil davon.

Aber noch ein paar Stunden, und die Aufgabe ist gelöst. Und wenn ich gemein bin, gebe ich das am Montag meinem Azubi......

Wobei mir jetzt beim Schreiben eingefallen ist das ich eigentlich ja nur eine fortlaufende Zahl benötige und noch nicht mal hex brauche. (Hex habe ich damals im COBOL Programm gemacht als die Kundenummer noch sechsstellig war und ich auf 5 Stellen mußte)
Man sieht, drüber diskutieren bringt häufig was.

GG 4250

... was soll da eine Function oder gar UDF denn leisten? Und dann auch noch in einer "ordentlichen" Programmiersprache, die Huddel eben gar nicht können soll?
Eine 4 Byte Integer hat einen Wertebereich von −2.147.483.648 bis 2.147.483.647. Also speichert man die Kundennummer als int. Für die 5 stellige Alpha Welt (COBOL) macht man eine DDS LF, die behauptet, dass das int Feld CHAR 4 ist (bleibt noch das eine Byte dazu zu huddeln). Wenn SAP keine int mag, dann kann man das Feld ja in einer SQL View als dec(8, 0) vorzeigen.

D*B

[KingofKning]

Hallo *all,
jetzt noch mal ganz langsam.
Die Aufgabestellung war bisher:
Nimm die Daten aus unserem Warenwirtschaftssystem von der AS/400 und erstelle damit Schnittstellendaten für unseren Außendienst (RP-Trade auf dem IPad).
Hat jahrelang mit einem Cobol-Programm gut funktioniert.

Dann kam ja jetzt letztes Jahr SAP und damit wurde dann alles besser und den alten Mist brauchte man nicht mehr.
Kaum ein Jahr später stellte man fest das der alte Mist doch eigentlich gut war und man es gerne wieder haben möchte.

Also muß ich jetzt die Konditionen der Verkaufspreise in eine Schnittstelle packen.
Jeder Kunde kann seine eigene Preisliste haben, einem Verband angehören oder nur z.B. Großhandelspreise haben.
Sprich im Kundenstamm wird hinterlegt ob Kundenpreisliste oder z.B. GH-Preisliste.
Bei ca. 1.500 Kunden mit jetzt 8stelligen Kundennummern muß ich also ein Mapping machen von 8 Stellen auf max 5 Stellen. Da ich es früher mit Cobol und Hex gemacht habe war das jetzt auch mein erster Ansatz. Aber in der Diskussion hat sich ja nun rausgestellt das ein normale Mapping von z.B.

Kunden-Nr 19645978 -> Preisliste 1
Kunden-Nr 68954556 -> Preisliste 2
vollkommen ausreichend ist.

Da das SAP-System bei einem bekannten Großbäcker läuft und ich leider da meine ABAP-Kenntnisse nicht anbringen darf, hole ich mir die Daten auf meine geliebte AS/400 und erstelle mir dort die Schnittstellendatei.
Und mein erster Ansatz war jetzt SQL, da ich den Aufbau der Daten für die Schnittstellen (Kundenstamm, Artikelstamm, Preislisten) mit Views erstelle die dann per cpy.. als Textdatei dem RP-Trade Server vorwerfe.

So langer Rede kurzer Sinn ich finde es schon schön was mit SQL so alles geht. Schade nur das man sich das alles selber beibringen muß. (Forum sei Dank auch Hilfe bekommt)

GG 4249