Blue Prism 7.0.1 Failing on function seperators

[FrankJelstrup]

Hi community, 

I'm from Denmark, I have English language set on and using danish comma for seperating numbers. This means function seperators and number commas will be mixed up.

Take this expression as an example:

Mid([Item Data.CPR], 3, 2) -> Will fail due to comma between numbers understood as decimals.

I solved this by using strings around the numbers to interpret them correctly as numbers and comma being interpret correctly as function seperators.

Mid([Item Data.CPR], "3", "2")

Is there a better way of doing this? I do like my computer on english language (easier to find help for random errors) and I like to use danish decimal seperator (comma).

In advance thanks 🙂

[John__Carter · Accepted solution]

Hi Frank - I'm glad you posted this because I have a similar problem that I haven't yet figured out. My workaround is to add spaces on both sides of the commas, eg:

Mid([Item Data.CPR] , 3 , 2) 

Can you try this and see if it improves your situation?

[FrankJelstrup]

Thank you John,

To use space as a delimiter is much easier than making it a string, good answer! Still it's very annoying that BP functions fails when using them directly due to comma being both delimiter and comma separator. Guess I'm creating problems for myself when mixing and matching numbers and string languages, trying to get the best from both worlds  🙂

[John__Carter]

Hi Frank - your post will help. I raised a support ticket when I had this problem but it got closed because the support team could not reproduce the error I was seeing. I'll reopen the ticket and add a link to your post. Thanks.

[stepher]

Frank,
What happens if you use all data elements/variables in your function?  I tend to do this as a personal practice, even if I expect the value to remain constant (say, a process name, a URL, height or width).  In your example, use a multi-calc stage with
   3 -> [Search]
   2 -> [Replace]

Then your function becomes: Mid([Item Data.CPR], [Search], [Replace])

More curiosity than an intended solution.  Good luck.
Red

[John__Carter]

Hi Frank - I have a small update for you. Your post has been useful and our engineering team are now trying to figure out how best to fix the issue. In my case I realised that I had my language preference set to English (Europe) on the BP log in screen. Changing it back to English (United Kingdom) made the validation disappear. I think the root of the problem is that the expression validator is confusing commas and decimal points.

[FrankJelstrup]

Hi John,

Thanks for looking into this. I think the reason is that both the decimal separator and variable separator are a comma (","). This means BP has a problem as xyz(123,123) can be interpreted as either 1 input with a decimal number or as two inputs with integer numbers. When there are ambiguity it's obviously hard for any program to make a logical decision. The way to make it non-ambiguous was as you said, put in a space, this will show it's not a decimal xyz(123, 123), hence it can only be a separator. This is my guess on this underlying problem 🙂

Hi Robert

If I use data items (variables) there are no problems. This is interpreted correctly.