ComputeKey original value not editable

[tbolhuis]

Something must have been changed recently on the way AppSheet handles “Key” values and the way they work with virtual/compute values.

I have a compute key that spits out a reference name, and is set as the “Key” value so that the contents can be referenced by other worksheets. Previously, I was able to edit the original data value (if compute value = original value, I can still change the original value and the compute key will also change). Now, however, the original value is not directly editable via AppSheet and I must now change this information via back-end processes. (the field is grey’ed out)

As soon as I disable the key for the virtual column, the field is again editable but I lose my references functionality.

Am I missing something here?

Any help appreciated!

[WillowMobileSys]

The only thing i can think of is that you were able to take advantage of a loophole and that hole was closed with recent changes. We should never expect to be able to edit/change a Key value, it can cause more havoc than you may realize.

[tbolhuis]

Except, I’m not really editing the key value. I’m changing what the key value references, which shouldn’t necessarily matter?

How would you recommend I get around this new limitation? I need to be able to change the information in these fields, while still being able to reference other tables (as you can see by the other virtual columns).

[WillowMobileSys]

Sorry, just now seeing your response. If you use the Reply button at the bottom of the thread, instead of inside a post, the reply goes onto the thread as a general reply and posters would not be notified directly - only if they happened to choose to “follow” the thread - which I should probably make a habit of doing.

Anyway I hope by now you have figured this out but here is what my response would have been.

Whether its a single column acting as the key, or its a composite key (two or more columns together), the effect is the same if you change any of the columns. I would argue that if a column can be changed by users at some point, it probably should not be part of the key.

They way I avoid these issues is by always using a dataless key - a dedicated key column. The only time I don’t is when the table is a very simple utility table such as a list of options for a dropdown.

This does mean you have to implement your own checks to make sure there is no duplication of entries if that is a requirement in the app.