I have been attempting to migrate the back end of my app from Google Sheets to the new database feature while performing some structural updates as well. I want to stay on the same deployed app, so I cloned the app to generate the database and perform the frontend changes. I then went through the tables of my deployed app and backed them up to a new database and switched them to the relevant database table. However, this generated the error:
"The given key was not present in the dictionary."
I found that the way appsheet handles key values is different with databases, and requires the usage of automatically generated row IDs. Fine.
So I cloned my app with a database to perform the frontend changes. The idea was to keep the legacy app running and then upgrade it with the clone. I would then clone the live data into a database to generate the row ID, and then point the upgraded app to the generated database with the live data.
However, I was testing this out with my cloned app, and I found something disturbing: Switching between the original database and an IDENTICALLY STRUCTURED database generates the same error. What's more: I CAN'T SWITCH BACK! Even when I point the table to the original database, the error persists.
Obviously, I'm hesitant now to switch to databases as it looks like any monkeying about with data sources has the potential to permanently break the app.
@Caleb1 wrote:
Obviously, I'm hesitant now to switch to databases
If your app is a "live" app or will soon be a live app, you do NOT want to migrate to the AppSheet Database just yet. It is a new feature in PREVIEW only.
In case you are not aware, "preview" features in AppSheet, there are several, are meant for app creators to test and report issues and/or suggest improvements. Its a way for us, citizen developers, to help shape the direction of the features.
@Caleb1 wrote:
I found that the way appsheet handles key values is different with databases, and requires the usage of automatically generated row IDs. Fine.
FYI, I strongly encourage you to implement keys in this manner in ALL of your apps. It is a more robust and SAFE way to handle row keys.
Gotcha, will hold off on migrating the backend.
Yes, my current app uses unique, app generated keys in the key column. However, it appears that the database feature forces the issue by generating its own column and creating its own keys even if a valid key column already exists. It creates some invisible backend link to ensure proper integration to the automatically generated database, I'm guessing.
The bug where you can't point the table source to a different, identical database is worrying, and doubly so when you can't point it back to the original database. I'm hoping that issue is ironed out before formal launch.
Also, PLEASE refer to it as "AppSheet Databases" since it's not actually A DATABASE, it's a PRODUCT.
I'm sorry if it sounds rude but man, it's harder and harder to help people with these confusions.
@ShirleyN do you think the name is going to change or that there will be a better reference / naming convention for a database vs AppSheet Databases?
User | Count |
---|---|
17 | |
11 | |
7 | |
4 | |
3 |