Hi AC,

I think what may be happening here is that the post code is first translating "N" to "London," then the dictionary picks up the "L" from the beginning of London to translate it to North West. Are you seeing any others follow this pattern?

There are a couple ways to resolve it. Sometimes, just rearranging the order of the entries will work, or you could change the value to match to be the letter followed by any number (rather than the letter followed by any character).

I hope this gives you something to go on, but let us know if you are still stuck.

Amanda Tetanich, bCRE
Associate Product Manager | Omatic Software

I think the easiest way to fix this would be to put a random character at the beginning of your replacement values. I'll use @ for this example. Value to match on UB.* replacment value @London. Next line value to match on DH.* replacement value @North East...and so on. Then on the very last line of the dictionary value to match on @ replacement value -BLANK- (with RegEx turned on) to remove the @ symbol.

Thanks,

John

John - that's a cool idea and would work well here, it seems!

Thanks for your suggestions guys. I really liked the idea of the random character but I couldn't make it work, it was giving me the same problem as before but Amanda's suggestion worked so instead of just UB.* I have UB[0-9] .* and it's feeding back the proper values.

Thinking about it further you'd also need to put ^ at the beginning of all of your values to match on (along with the special character in the replacement value). It was still matching on L because it was somewhere in the string, but ^ would force it to only look at the beginning of the string for a match. As long as it's working one way or the other that's all that matters!