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!!
