Problem with replacing data

my app allows my customer to provide a data table that is a list of voters, and the app builds them a map and a survey to give voters. The customer would be using the app to contact voters across the country, so there would need to be an option to use a new table with new data. However, when I attempt to add in a new table of voters and remove the prior one, it gives a warning that all the components of my app will be deleted. Is there a way to accomplish this where I would be able to upload a new data sheet and remove the prior one, or will it always delete the built features of my app if i remove the original table?

currently the only thing i can think of is to add in the new table, update the entire app to read off of that table now, and then delete the prior table. but, if i miss one feature that is still assigned to the prior table, it can break something or remove something and cause problems.

Can’t you just delete old data and upload the new data to that same table, assuming they’re the same structure?

Deleting a table, as the warning said, will remove all components for that table.

1 Like

I’m not sure how you mean, f go you mean just copy and paste? I’m not sure how clunky that works be when there are thousands of rows


You can right click on the table and click Import.

1 Like


Are your data tables Google Sheets or Glide tables? I think they are GT right?

If so, use the Replace option to get what you want.

Glide will replace your old data and keep the same components already configured.


So if my client has multiple volunteers in multiple states on the same day using the app with different data in each state, will i have to create a new copy of the app for each one? I dont understand how to make it work with just adding to the same spreadsheet.

One app means one central source of data. It seems that you want to be able to have separate data sources for different users. That’s not how it works because the data is ultimately stored on Glide servers, and the app refers to that central data store.

Your options are to create multiple apps, each with a different data source (and make extra work for yourself because you have to maintain multiple apps), or create one app with one set of tables, but use the appropriate Filters and Row Owners to determine who can see what.

Screens and components become deeply attached to their underlying table, so removing a table and attempting to replace it with a new table means it’s a brand new connection, so existing screens and components will break.

Rather than rebuilding parts of your app every time you want to add new data, you should be using the existing tables and import new data into those existing tables. There is an exception with google sheets where you can fully replace one google worksheet with another, but it sounds like you will have multiple users using different data at the same time, so fully replacing a google worksheet would not work for you. In that case, you are better off utilizing filters and/or row owners depending on how secure the data needs to be. It would be one set of tables and you just need to import additional data as @ThinhDinh pointed out above.


Okay i was suspecting row owners would be the answer, but it honestly really confuses me how to set that up. i have read the documentation and seen some videos on it, but are there any videos available where someone shows a similar process and how to order the data this way?

another problem is that i my cap out how many rows are needed very quickly. I was thinking i would need a business plan and to use the added features of bigquery or bigtables to link to my data outside the app, but i am not sure how that works, i have spent a few days trying to research it and now getting very far in my understanding

Here are some videos that may be useful if you haven’t seen them.

Row limits are definitely a consideration depending on how much data you have. I personally have not worked with big tables. There are some minor limitations as far as using some computed columns with them. Also the fact that only small chunks of data are sent to the user device at any one time. Normal tables send all data to the user device immediately when they open the app. Also, if multiple users are updating data in a big table, it does not automatically sync to all other user devices. That new data needs to be refreshed by the user. This is unlike normal tables, which keep everything in sync on team time. But it all depends on what you need and how you will use that data. For the most part, they should work very similar to normal tables.


Above is the list of limitations. You have to deal with many things and if you plan to use it, I advise to use it with the 14 day trial of business plan so you can know if you want to work around those limitations for scaling purposes. If you use a normal table now and want to change it to a big table later, chances are that you will have to rebuild a lot of things.


I have tried implementing the import data feature to add new data to my original table and am not able to get it to work, it crashes in all the methods i have tried. Continued Problems replacing data