However, if I export only Title column from my first app (without Row ID) and import only title into new app, everything is imported, but Row ID is generated automatically and I lose links to bunch of other tables.
This is the only table (but a key one) where import doesn’t work and I am desperate I cannot port data to a new enhanced app version.
The Row ID is assigned by Glide and cannot be imported. Is there a reason you are importing and not just attaching the other table to your App? If you have links to other tables, I am assuming the table is available in your team to be attached, rather than “imported”.
No, but there is no need to delete it right away. Make sure everything works in the new App. I’d leave it out there anyway, just don’t go into it once you’ve changed anything in the linked files (columns, etc.).
I’d reconsider what @David_Gabler is saying. Link the existing tables and use them instead. Then you can migrate to the new app when you are ready without having to bring down the old app just to allow time to migrate data without users interfering by modifying data in the middle of your migration. If you link the existing tables, there is nothing to migrate and switching users to the new app should only take a minute or two.
I’ve been working on a new version of my existing app for a few months. Both old and new apps share the same tables. The data is always in sync. When I’m ready to switch it’s just a matter of pointing users to the new url. Since the data is kept in sync I don’t have to mess with exporting and importing data, which is error prone. When I’m ready I’ll just delete the old app. Deleting an app doesn’t delete the tables.
You can’t export data with RowIDs and import back into the same table, even if you delete the data after exporting. This is because when you delete rows they aren’t really deleted in the back end, but rather marked as deleted. So when you try and import data with the same RowID values they will be detected as duplicates and the import will silently fail.
Yes, this is expected.
What you will find is that you can import the data with the RowIDs into another table, or a duplicate of the original table, and the RowID values will be preserved. You just can’t import them back into the same table.
Only partly true. See what I said above.
This what I would normally recommend as well. Although there are times where you do need to keep multiple versions of an App completely isolated, with each version having its own independent set of tables. I’m in this situation with a client that I’ve been working with, where they have 3 separate “environments” - Dev, UAT, Production. Each environment has its own database on their side, and I’ve had to mirror this on the Glide side. So at any given time, I’ll always have at least 3 copies/versions of the same App in play, and none of them share any tables.
I have never used linked tables before. Tried following your approach with linking to tables from my old app version - but it is too late.
When I link old app table into a new app - it imports it correctly but then I would need to replace all references throughout the app to point to new linked table.
It seems that right approach would be, whenever I duplicate the app, instead of copying tables, I should chose option “same tables” rather than copy tables.
I currently have 3 tennis clubs that are using my app. Each club currently has its own app instance with a separate database (Glide tables).
My goal is to have a single app with a single database for each club. So each club can log in and be automatically directed to its own data.
From what I can see, I will have problem with migrating from 3 different DBs into a single one as I used Row IDs to identify Players, Groups and many other entities in my app. It would be much smarter if I used a separate identified for each linked table, to avoid Row ID importing issues.
Any hint on this? Migration from 3 different DBs into a single app DB.
It should be possible to merge all three and keep existing RowID values intact.
As I mentioned earlier, RowIDs can be imported, as long as you aren’t importing back into the same table.
To me it sounds as if clubs could be sharing tables/databases and you could be using row owners or role to segregate data. Each club would then own their own sub-table of each table.
Well I never tried importing Row ID into original table. Why should I do that?
Here is what is strange
Old app:
Table 1 : row id and title
Table 2 : row id and title
New app:
The same table names and structure
Exporting Table1 with RowID and importing it into Table1 into the new app - OK
Exporting Table2 with RowID and importing it into Table2 into the new app - FAILS
Not sure how long it’s been like that, but when I made a copy of a table, and then added a Row ID column, it auto-generated all the Row IDs and would not let them be over-written with the original Row IDs. Perhaps you have to do it in a certain sequence for it to work just right.
I wonder if you could lay out a step-by-step plan for dealing with row IDs in a conversion from Google Sheets to Glide Tables.
Production version uses Google Sheets for two main tables (Jobs and Items) and Glide Tables for most everything else.
Dev version uses new Glide Tables for Jobs and Items and linked Glide Tables from the Production version for everything else. I had been building out the columns and relationships in the Glide Table versions of Jobs and Items and planning to import right before going live with the new version. But it’s looking like I’m not going to be able to get the Items table imported with the same Row IDs.
Will I need to import to a new Glide Table to preserve the original Google Sheet Row IDs, and then build out all the columns and relationships? I was hoping to minimize the amount of time between final testing and switching the users to the new app.
Update: I think what I need to do, is start with a new Glide table that doesn’t include any Row IDs from the original Google Sheet. Re-build everything with this new table, then when everything is set up, delete all the rows and import the Google Sheet, with its Row IDs.
The key seems to be, don’t allow any Row IDs that are used elsewhere to get imported and deleted, because they won’t be able to be imported again.
