Copy Glide Table

Good morning Community! I would like to ask if it is possible to duplicate a table created in GLIDE (copied with another name of course) but copy the original Table both with regard to value fields and with regard to fields with Glide formulas created in the original table ???

We have a table in GLIDE with monthly data from a company and with additional calculations in specific fields with mathematical formulas created in GLIDE and we would like them to be copied as well when copied (and not have to replicate them again…).

Thank you very much in advance.

Greetings,
Javier

Are you trying to duplicate the table to use in the same app, or to use it in a different app? While you can duplicate a table, it won’t keep the computed columns.

The only way to duplicate tables while retaining the computed columns is to duplicate the entire app and select to duplicate the sheet as well. Doing that will duplicate the tables and keep the computed columns as well, but those computed columns will only be available in that duplicate app.

Other than that, you will need to recreate the computed columns again.

1 Like

Hello again!
Thanks @Jeff_Hager
I am trying to duplicate the table and the calculated columns in the same application…

What we want is to create a table for each month of the year (so that the number of rows is not too large…) and we have rows calculated in, for example, the month of January and we wanted to “duplicate the table to February, March,. …” to enter the values ​​in each of the months. But we had the columns calculated and they were quite a few… so if we cannot “duplicate everything” it will be unfeasible…

I guess we will have to rethink it to have only 1 table with row records for an entire year (and in the following years we will see how to solve it).

Thanks for the information and now we know what to expect…

One final question…how many rows in a table is it “reasonable” to have??? The same as the limitation of EXCEL itself???

Thanks again
Javier

1 Like

Yeah, I think one single table with data for all months makes more sense. It’s just going to make maintenance a lot easier because you are not duplicating any future changes to the tables or the screens 12 times. You can do it once and be done.

Theoretically 25k rows is the limit for a table, but also for an app that does not use high scale data sources. I think it really comes down to the types of computed columns that are used in your table and how they are configured. I have an app with a table that is close to 10k rows. For me it’s really slow performance wise on initial load, but each row relates to other rows in the same table, and some of those relations require other computed columns to work. Plus there are relations to other tables. It’s a bit of a hot mess in my case because several tables are all intertwined and dependent on each other, so I can understand why it’s slow for me. I’m requiring all rows to calculate and relate to each other all in one shot as opposed to rows only performing calculations as needed to display on the screen, so for me that initial load takes a bit. For other people, they could probably have 25k rows with no performance issues at all. It really just comes down to trial and error to find out for sure.

If your calculations are only being performed on a row by row basis, then I think you will be fine having severe thousand rows in the table. There is no way to predict performance issues since there are so many variables to consider.

Technically yes. With Excel, you have to consider the extra sync time, but ultimately the data is stored on glide servers and the app only works with Glide’s copy of the Excel data. Also note that most computed columns are actually computed client side, so each user’s device is actually doing the heavy lifting. Only the basic column data is synced back and forth between client and server. So in my opinion, external data sources are just a synchronized copy of data that’s also stored on Glide, so it’s almost like you are still working with Glide Tables…there just happens to be the extra backend process of syncing between Glide and the external data source.

3 Likes

Thank you very much @Jeff_Hager for the content of your response again ;).
Take note ;).

Thank you
Greetings,
Javier

1 Like