Latin letters with diacritical marks (trema or umlaut), such as ë or ö, register in code in the XML. When retrieving the repeating section form data and writing this data to (another) list, these letters still show code. For example "cliënt" (client in Dutch) is registered as "cliënt" in the list.
How do I solve this?
I could prevent diacritics being used on the form by putting in the regular expression [a-zA-Z] but this isn't my preferred solution because then technically words would be spelled wrong. Is there any other way to clean up the XML?
Solved! Go to Solution.
how do get the data at one end and how do set them at the other?
it looks like the two do not work the same way in term of encoding/decoding special characters within XML.
have a look on fn-XmlDecode() / fn-XmlEncode() inline functions.
Thanks for your reply!
I use a UDA to get the repeating section data.
Then a for each loop to do a Query on the XML of each item in the repeating section, saving the form data from each field to a variable. For example Output 1:
Then at the end of the loop the item (row) from the repeating section is being created in a another list:
The return type for each field is string (standard):
I have now added a couple of build string actions to decode the variables using fn-XmlDecode() before I create the item in the list.
It works great but it does mean adding a lot of extra actions. I will have to add these actions to all workflows in which we gather information from a repeating section and either write it back to the same or another list. It’s strange how I haven't noticed this was needed before.
Maybe there's a different return type I should have selected?
great you managed it to work.
I will have to add these actions to all workflows in which we gather information from a repeating section
if you haven't experienced problems up to now, those other workflows probably do not work wit such un-/de-code sensitive data. so maybe you could let them untouched and correct them just when they fail.
Maybe there's a different return type I should have selected
no there is not any other (XML - native) data type that would handle that OOTB.
maybe you could consider updating UDA so that it returns already encoded data.