I just duplicated a table thinking (hoping) that it would duplicate the computed columns. To my surprise, it duplicated the DATA (which I did not expect), but did not duplicate the computed columns.
I could have sworn it used to do that…
Help?
I just duplicated a table thinking (hoping) that it would duplicate the computed columns. To my surprise, it duplicated the DATA (which I did not expect), but did not duplicate the computed columns.
I could have sworn it used to do that…
Help?
Well @Glide, it’s nice to know that I was right and the computed columns should have been duplicated also, but they were not, and from the sound of it, I was also right in expecting the duplicated table to be empty.
The bot is wrong and tends to make a lot of things up.
It has always been the case that when you duplicate a table, the data will also duplicate, but no the computed columns will not duplicate. It’s never been any different. The only way to get the computed columns to duplicate is to duplicate a project that uses that table.
OK so that’s a clever work around. I’ll duplicate the app and say Duplicate table And then I’ll rename the one I want and add that to my 1st app. I’ll see if that works. Thank you for not making stuff up.
Hehe, I try not to.
I don’t know if that will work for you though. It will duplicate the computed columns for that new app, but adding an existing table to a project won’t preserve the computed columns. If you’re trying to get a duplicate within the same app, I think you’ll ultimately be stuck with re-adding all of the computed columns.
I hate to ask a really stupid question, but I’m curious: what’s the reason for duplicating a table and needing the computed columns and the underlying data in the basic columns being different?
The only scenario I can think of is trying out something and not wanting to mess up the original table.
An idea if you are duplicating the table for testing purposes like tinkering while adding a new feature but not being sure it’ll work: you can add a new set of columns, group them together and should the tinkering fail delete that group of columns only.
The reason is because I need rows that are not affected by row owner. If we could have a feature where if the row owner were blank it would show for everyone that Would be great because then I wouldn’t need two list views et cetera.
I agree. I wish empty row owner cells would be global for everyone.
Gotcha.
One use case where I would like to be able to duplicate or link a table and keep all the computed columns is with a Helper table. In most cases, a Helper table only contains computed columns, or at most just a handful of non-computed columns. As it is at the moment, if I link or duplicate a Helper table, I pretty much get an empty table.
Taking this one step further - I’d love to have the choice. Either/or on a per table basis
Rethinking this. We would need a setting on the row to ignore row owner, because I do have tables with multiple row owners where one or more is empty. Perhaps ignore if all are empty.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.