An easy question. I am testing an app migrated from a classic. For testing I’m using a test gsheet; next week I’m going to change the gsheet and put the production one and check that everything is ok. In the migrated app I created an auxiliar/complementary glide table …when I change the test gsheet in the app for the production one, will I lose the glide table I created (I guess it will stay and maintain associated to the app…)
Thanks in advance
I don’t think the Glide table will be any concern.
I’d be more worried about swapping the google sheet. I seem to recall that it is possible, but it’s not something I’ve ever attempted. I’d be more concerned about losing any components, screens, and logic associated with the test google sheet.
I think I would duplicate your new app and try it there first to make sure it works.
I’ve done it, but only ever with a backup or copy of the original Google Spreadsheet.
I believe it works fine, as long as the individual Sheet and Column names are identical. But if there are sheets/columns missing or having different names, then I’d expect that’s when you’d start having problems.
I agree, testing in a duplicate is always a good idea.
Yes, I was thinking of making a copy earlier.
However the new gsheet is the same as the existing one but with a lot less rows…
in this case it should work…right?
According to @Darren_Murphy it should work.
Thanks
Even if swapping Google Sheets seems to work, if it were me and especially if the application is important (or will be on the long term), I would rebuild.
My reason is mainly due to stability and durability concerns. When a Glide apps uses a Google Sheet as a source of data, I imagine that under the hood, a ton of authentication and data binding is happening. I don’t know if “data binding” is the correct terminology. But I can imagine that Glide looks at a Google account ID, a Google Sheets spreadsheet ID, a Google Sheets sheet ID (the tab) and column IDs. If you swap a Google Sheet spreadsheet for another and just by keeping the same column headers (labels) things bind correctly, then that to me is a bug. It’s a practical bug that makes life easier, but it’s still a bug. The day a developer at Glide fixes the bug, things could start breaking.
I’m probably paranoid unnecessarily and it stems from not understanding how the plumbing and nuts and bolts of coding actually work, but still, in your case, especially if the rebuild is simple and fast enough, I would rebuild clean.
Considering it’s a specific built in feature unique to Google sheet data sources, I would not call it a bug.
Many of us have specific reasons for using Google sheets. Although I will promote Glide tables all day, not everyone falls into the glide table bubble, and besides, there is no reliable automated backup and restore feature within Glide that is accessible to us developers. I primarily use glide tables for most projects, but I have one that uses google sheets and would be a disaster if I lost my data. With Google sheets I have automated backups and separate control of my data that is not fully dependent on Glide. I don’t think we can discount those that choose to use other data sources.
I misunderstood the exchange above and now I totally agree with you. From the exchange, it seemed to me like Jesus was removing a Google spreadsheet, adding a new one, and somehow with the same column headers things bound well.
I didn’t realize Replace was a built-in feature. I would trust it more then, now that I know it’s a native feature.
Still, if it were me, I think I’d feel better rebuilding (I have nothing against building on Google Sheets by the way) 
Hey, I avoid copy-pasting components, I prefer building them from scratch. Just in case.
The reason I want to change the current gsheet is: the current app comes from a classic migration done 2, 3 weeks ago (actually it’s the third attempt, the first two ended with two unrecoverable crashes-blank pages; the support team is aware), to avoid editing or deleting inadvertently data from the production gsheet, I replaced the production gsheet with a copy to which I then deleted most of the rows (the pro version has 16,000 rows). With this version I have been tweaking practically all the windows/app (and adding in some cases new functionality such as speech-to-text transcription).
Now this version is stable and ready to be put into production. To do this I need to replace the test gsheet with the PRO one. First I have to make sure that the small changes I have made in the test gsheet are reflected in the pro gsheet (these changes will be done manually).
Then I have to test again in a very detailed way that everything is still ok. (note: The glide table I have added has no relation with the gsheet, I have used it for a new and complementary functionality).
The migration process is proving to be tortuous and time consuming. However I still think Glide is a fantastic app development platform.
Thanks for your comments!!!
As I mentioned in one of my earlier responses, as long as all sheet/column names are identical, you should be fine. I have done this numerous times and it always works perfectly well.
But again, be sure to do a test run with a duplicate of your App to be absolutely safe.
Thanks Darren!!
Hi
Following the steps to migrate my classic app, I already have a migrated version but linked to a test gsheet. The goal is to replace this test gsheet with the PRO one. The test gsheet was a copy of the PRO one with most of the rows removed (to make it lighter). The changes I have made in the test gsheet I have meticulously replicated them in the production gsheet. When I try to do the replace in the Settings->Data->Data sources…after a while I get the following message
…
I have checked again the existence in the Users tab of the columns mentioned in the message and all these columns are properly replicated… I have even deleted and edited again some of these columns and the result has been the same…
As the columns are from the ‘Users’ tab I tried to search through the configurations and I have seen that if I click (in the Data->Data Sources section) on the button of the name of the equipment/installation, I get a screen with the possibility of linking tables (apparently of the system…?) and I see that there are ods ‘Users’ tables…
Could this be related to the error it gives on the attempt to replace the gsheet?
They are native tables - not linked to any Google Sheet.
As long as you are testing in a copy of your App, I would try clicking the “Remove Features & Replace” button. Sometimes Glide seems to get a bit confused with that one.
But if it really deletes the features (…) it means that I have to go through almost all the screens since in Users certain permissions are set per user…? ¿¿??
That’s why you test it with a duplicate app. I’ve seen that message in the past, and in many cases it didn’t delete or break anything. We’re talking several years ago when people did a lot more logic inside Google sheets.
I used to have tables that were dynamically built using formulas (including the heading row). If Glide synced at the same moment that the table was rebuilding and was completely empty, then I would get the warning. Problem was that Glide would put a hard stop on syncing. It saw for one moment that the columns did not match, but would not look again to see if they were restored. Pushing that button was blind faith that it would work and a lot of times it did.
I’d say that there is a good chance that it won’t break anything at all, but that’s why we test things first.
