February 25, 2019 at 18:06 #23950
I’m wondering if you could help with an issue I’ve come across.
I’m using vLookup to create a quick way of finding a duplicate entry in a list of unique values, so if someone tries to save an item that would prompt the sharepoint error “This value already exists in the list.”, vLookup will present that item, and let the user edit it directly.
The issue I’ve encountered is that my unique field includes accountName (as text), in the form domain\username. It appears that the backslash character is invalid when it comes to vLookup. See the attached screenshot.
I’ve tried a lot of other characters, and the only other that I’ve found which causes a similar problem is a double quote (SyntaxError: Expected ‘}’).
Is there anything that can be done to make this work, other than deleting or substituting characters in the string?
SharePoint 2016 on-premise
DFFS frontend: 220.127.116.11
DFFS frontend CSS: 4.46 / 4.46
Cascading dropdowns: 3.7.25
Resource management: not loaded
February 25, 2019 at 19:42 #23959
February 26, 2019 at 01:57 #23971
Thanks for the fast reply.
A backslash on it’s own causes the error – it’s expecting a valid escape code because the backslash is there. Backslash followed by a non escape code character generates the error message and kills the vLookup.
A backslash as a valid escape code ( \n \r \\ etc) doesn’t error, and the whole string is then successfully used in the vlookup query.
For example; domain\rtester works as \r is a valid escape code.
I’ve attached some more screenshots to help illustrate. Firefox gives a slightly different error message to IE, specifically calling out a “bad escaped character”
February 26, 2019 at 21:48 #23984
You are right – I tested it with valid escape characters and did not get the error.
Unfortunately it is not so easy to fix it because I use JSON.parse to convert the JSON string for the vLookup config into a proper object and it is difficult to replace the \ in the text.
Are you able to replace this character in your code – before you write it to the field?
February 27, 2019 at 21:08 #23996
What I’ve done as a workaround is left the field that needs to be unique as it is (essentially the accountName taken from a people picker and a value from a choice field joined together), so SharePoint takes care of enforcing unique values.
For the vLookup I’ve swapped from using the unique field on it’s own as the filter to using the people picker AND the choice field as filters. The end result is the same.
It’s actually quite a neat solution that stops users getting to the point of saving and finding that they can’t do so.
Excellent functionality made possible by DFFS.
February 28, 2019 at 19:42 #24006
I’m glad you were able to work around this limitation.
You must be logged in to reply to this topic.