There is a syntax error, but it’s apparently not the one Panorama thinks it is. As you have written it, those semicolons aren’t part of any string, so Panorama is apparently accepting them as delimiters between parameters.
Try writing them as
replaceMultiple(«Name»,'";%',"%22;%25",";")
That should fix the syntax, but I think you are doing them in the wrong order. When you are encoding something with an escape character, the escape character itself should be encoded first, and decoded last.
Thank you Dave. The less than accurate compile error was a distraction that prevented me from looking beyond it. And yes, the array should be quoted rather than the elements of the array. I did miss that.
When this replace( function became a necessity, I was only dealing with having to escape the ", or the ', and there was no need for the escaping the the escape character. But then life interceded and it too became an issue. I’m not quite seeing why the order will be important but I am sure time will show me that you are spot on.
When you see an error like this, it generally means that the parser got confused by something in between the parenthesese. Semicolons are accepted as separators in text funnels, and the same parser is used for parsing text funnels and function parameters. So I think it is not really handling the semicolon as a separator, but it’s not recognizing it as an immediate error either. I notice that other characters do produce an immediate error, for example a period or a dollar sign. Also, a semicolon will produce this error in any multi operand function, for example
max(4;7)
Separately from the error message issue, I think that replacemultiple( is a bit of an awkward function to use. Now that replace( accepts multiple parameters, I think it is much clearer and I always use that instead. The only exception would be if for some reason I need the list of replacement characters in a variable.
Here’s why. Suppose you have this text.
"90%"
Now suppose you start by replacing " with %22. You’ll get.
%2290%%22
Now if you replace % with %25, you’ll get
%252290%25%2522
But that’s not the correct answer. What you actually want is:
%2290%25%22
And that is what you’ll get when you reverse the order of the replacements, as Dave suggested.
However, when reversing the process, I don’t think it matters what order you use.
I don’t think it will matter if those are the only two characters you are encoding, but let’s say you are also encoding spaces, and the original text just happens to contain %20, perhaps because the subject of the text is url encoding. If the % symbol is the first to be encoded, and also the first to be decoded, then it is correctly encoded as %2520, but when you decode, the first replacement reduces that to %20, and a later one further reduces that to a space, instead of leaving it as %20. It follows from Murphy’s law, that I always make the escape character the last to be decoded.