Zitat Zitat von KingofKning Beitrag anzeigen
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