ComputeKey original value not editable

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!

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.

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).

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.

1 Like