I've been using unique index access on a row index formatted as object. The problem I'm encountering is adding two erroneous paths (imagine renaming objects so that their references are not longer valid). This triggers the pop-up telling me that the added one isn't unique. This is also the case when moving from an absolute path, i.e. from .Models.Frame.SingleProc to *.Models.Frame.SingleProc. This seems unneccesary to me, since it should be the same identiifer. In the case of cells marked red, they should be ignored when evaluating uniqueness.
See the attached model, adding an additional erroneous path is not possible. Trying to change the first path to *.Models.Frame.SingleProc doesn't work either, without cutting the path and reentering it. Is this by design?
Solved! Go to Solution.
The table considers two object to be the same, if the referenced object is the same. So, in your example, 'SingleProc', '.Models.Frame.SingleProc' and '~.Frame.SingleProc' would all reference the same object.
If you enter an ivalid path, the table considers the referenced object to be VOID. Therefore two invalid paths are considered as non-unique. If you want to enter more than one invalid path, you either need to disable the "Unique index key", or you need to use the data type "string" instead of "object".
When you edit a table cell in a way that the new value still references the same object, the table should ignore the old value when it checks if the new value is unique. Apparently this is not true. So you need to delete the old value '.Models.Frame.SingleProc' before you enter the new value '*.Models.Frame.SingleProc'.