DSXchange

To me, "keeping" in this context means "transferring into the result". Perhaps "using" would have been a better participle.

I agree. Being anal, the function only 'keeps' the delimiter if you tell it to return multiple delimited substrings and then only between the instances. So 'using' would have been more accurate. And to continue the theme:

ssnegi wrote:So the field operator does use the . as delimiter for extracting from a decimal.

That wasn't what was being discussed, especially since you specified a period as the delimiter. It was the question 'does the function work with a decimal' and the answer is still officially 'no' according to the documentation. And for all we know that only 'works' in your specific version, something thing we've seen before.

We've seen plenty of examples here where people think something is working as they'd like when in fact they are taking advantage of a bug... and then a future update closes the loophole and things 'mysteriously' break. So I would suggest rather than posting something like that, take the time to use the function properly inside the Field function. That would make it 'future proof'.

Actually, in this specific case, there is probably an implicit conversion performed from decimal to string, since the Field() function requires a string data type as its first argument.

I prefer not to rely upon implicit conversions in parallel jobs.

I was assuming the same thing, only way I can see it working. And like you I try not to rely on implicit conversions... unless we are talking Server jobs, of course.

This will convert the decimal to String before the field function call.