@Tammi_Canelli A possible reason why everything disappeared when you changed the key away from the row number is that any references you had in your tables were still set to the row number. So AppSheet was trying to find the row number in a different column, but couldn’t because that different column has unique IDs, not row numbers!
So the challenge in changing keys is finding a way to keep all those stored references working even though you’re using a new column. One way is to update all the stored references to their new values. That’s very tricky, difficult, time-consuming, and will break your app during the process.
To move to a new KEY column, try this process:
- Add the new column in your spreadsheet that will eventually become the KEY column, but do not mark it KEY yet. 2) Regenerate the table’s column structure in AppSheet to pick-up the new column. 3) Configure the new column in AppSheet as desired, e.g. with an App formula of =uniqueid(). SAVE these changes. 4) In the spreadsheet, fill in the cells of new column with their corresponding row numbers. 5) In AppSheet, change the KEY column from [_RowNumber] to this new column and SAVE the change.
That should complete your switch. If any rows were added in the time between steps (4) and (5), they may not have the right key value in the spreadsheet. Try your best to complete these two steps quickly, before a user has time to add any rows.
What this process does is sets up a new KEY column, but reuses existing key values to avoid breaking existing references that use them. We can do this because, in this case, there are no special requirements for the content of a key value other than it be unique. We are not required to provide key values 8 characters long composed of random letters and numbers (though that’s what uniqueid() provides), so providing a series of digits that happens to correspond to the row number at the time of the KEY column switch is perfectly acceptable. Note, too, that once the switch is complete, the fact that the number was once a row number becomes immaterial: if a row number changes, its KEY value should not change.