View Full Version : DB2 / SQL / String auf gültige Zeichen prüfen
Nimm besser den %TRIMR() anstelle dem %TRIM().
Ich arbeite in der For-Schleife absichtlich mit Trim, da ich eine größere Menge Sätze bearbeite und das ganze spürbar langsamer wird, wenn man die gesamten 5000 Zeichen durchläuft, auch wenn evtl. nur 200 Zeichen belegt sind. So ist es wesentlich schneller und Leerzeichen am Anfang kommen bei mir nicht vor.
... wieso wollt ihr da eigentlich mit Gewalt trimmen???
Das sauberste ist:
d cleanString PR 65535 varying
d EXTPROC('MYMOD_cleanString')
d data 65535 value
d varying
Procedure Interface entsprechend. Wenn die aufrufende Procdure korrekt arbeitet (im varying Feld zusammen bastelt, oder trimmed (wie es ihr schmeckt) passt alles, ein varying Feld weiß wie lang es ist!!!
Wer jetzt Angst vor Nano Sekunden hat, nimmt statt VALUE halt CONST, hoffentlich im vollen Bewusstsein, das CONST in Wirklichkeit hopefully CONST ist. (BTW: Performance entscheidet sich an anderen Stellen!)
Wer noch mehr Angst hat, nimmt Returntyp.
Bei ultimativen Angstzuständen nimmt man dann call by reference, muss dann aber sicherstellen, dass die Länge des Parameterstrings korrekt zurückgeht.
D*B
Und wenn eben UCS2 dann "65535C" oder die Free-Alternative.
Und was hat die Übergabe mit dem Returnwert zu tun?
Die Übergabe als Parameter darf und soll ja auch nicht geändert werden.
CONST ist also durchaus erlaubt.
Vielleicht heißt es ja auch VARUCS2?
CONST und VALUE haben ja gerade den Vorteil, dass ich beliebige Parameter übergeben kann.
Also bei Dieters Beispiel:
D MyChar 20
D MyVarC 20 inz('ABC')
CleanString(MyChar) => Übergabe von 20 Zeichen (mit Längenangabe vorneweg)
CleanString(MyVarC) => *bergabe von 3 Zeichen (auch wenn max. 20 möglich wären)
Gerade das ist ja der Vorteil von varchar/varying.
Und wenn eben UCS2 dann "65535C" oder die Free-Alternative.
Und was hat die Übergabe mit dem Returnwert zu tun?
Die Übergabe als Parameter darf und soll ja auch nicht geändert werden.
CONST ist also durchaus erlaubt.
Vielleicht heißt es ja auch VARUCS2?
Ich wollte aber gerne den geänderten Wert des Unterprogramms wieder im Hauptprogramm nutzen - deshalb muss der Parameter sehr wohl geändert werden. Ich hätte natürlich die Variable auch Call-by-Reference übergeben können, wenn ich denn gewußt hätte, wie das geht.
CONST und VALUE haben ja gerade den Vorteil, dass ich beliebige Parameter übergeben kann.
Also bei Dieters Beispiel:
D MyChar 20
D MyVarC 20 inz('ABC')
CleanString(MyChar) => Übergabe von 20 Zeichen (mit Längenangabe vorneweg)
CleanString(MyVarC) => *bergabe von 3 Zeichen (auch wenn max. 20 möglich wären)
Gerade das ist ja der Vorteil von varchar/varying.
Die Übergabe lediglich der benutzen Zeichen des Strings hat ja nicht funktioniert, wie ich oben beschrieben habe. Daher muss ich den String im Unterprogramm auf jeden Fall trimmen, weil ich bei 3 Zeichen im String nicht 5000 Schleifendurchläufe machen möchte.
Die Übergabe lediglich der benutzen Zeichen des Strings hat ja nicht funktioniert, wie ich oben beschrieben habe. Daher muss ich den String im Unterprogramm auf jeden Fall trimmen, weil ich bei 3 Zeichen im String nicht 5000 Schleifendurchläufe machen möchte.
... dann machst Du was falsch und dann gehört der Fehler abgestellt, anstatt einen Fehler mit einem anderen zu kompensieren...
Tut mir Leid, dass ich das mal so sagen musst, dann hast du es immer noch nicht verstanden:
Sieh dir die Definition an:
<code><code>d cleanString PR 65535C varying
d EXTPROC('MYMOD_cleanString')
d data 65535C value
d varying </code></code>
D.h., die Funktion wird mit einem Feld aufgerufen und gibt ein anderes Feld zurück.
Also es werden zwar 65k Zeichen übergeben, aber durch %len() nur die Anzahl Zeichen verarbeitet, die gefüllt sind!
Ansonsten gibt die Funktion den geänderten Wert zurück:
NeuerWert = cleanString(alterWert);
Also in deiner Routine dann "return $temp;"!