How do I duplicate a page without it being tied to the original page?

I want to duplicate a page and use it as a template. Right now, the page I create a copy of ties changes with the original page. I just want to use it as a template and input new data without changing the rest. Right now I have to create an empty table and reinput the column headers 1 at a time and there are 7+ columns, which is cumbersome. I’ll need to make 20+ of these pages.

Another workaround I can think of is creating the template as a CSV and import it as a new page each time, but I’d like to streamline my workflow as much as possible. Any thoughts or tips is appreciated, thanks!

Hello @senojgnip, and welcome to the forum!

When you have multiple sets of data with the same structure, my advice is to keep all data in a single table, separated by some field, and to use widget linking to allow selecting and working with the different subsets.

This is the approach typically used in databases. For instance, let’s say you are an interior decorator, and for each client you’d like a table of furniture items you’ve picked out for them. Rather than placing them into separate tables (as you might in a traditional spreadsheet), use a single table, add a Client field to it, and create a linked view where you select a Client and see all furniture items connected to that one client. You will still be able to work with that linked table as a regular spreadsheet.

There are several benefits: any improvements you make to the structure (e.g. formulas, column formatting, etc) would apply to all clients without having to manually copy changes. Also it would allow you to summarize data easily across all clients, as well as to create views linked in a different way (e.g. if each item is tied to a supplier, you could create another view to select a supplier and see all items for all clients that come from that supplier).

There are some situations when this advice might not apply – if you have doubts, perhaps you can share more about your use case. But I’d say if you need 20+ of similarly-structured tables, then it’s quite likely that unifying the data is the best approach.

1 Like

That makes a lot of sense - thank you for the in-depth answer, I will implement it right away.

1 Like

@dmitry-grist But what if I only want to copy the headers? Is there no way to copy without linking?

You can export a table as CSV, and then import this CSV as a new table, and you’ll get a copy of the headers. However, the point of my answer was that if you are doing this, you are duplicating structure, and losing valuable benefits of Grist (or any database). That’s why I generally recommend keeping such data in one table, and designing suitable views instead.

1 Like

This isn’t always true, let me give you an example:

I’m going to parse some products daily into a single table and I’ve more than 10 columns in it (price, stock, discount, current title, etc.)

I’ve a master table with ~20 columns. 10 of them are entered only once (category, type, manufacturer, etc.) at the first entry and 10 others must be the last result from the first table for the corresponding product.

So if I keep everything in a single table, I’ve to keep a huge overhead (about 500 cells daily) in my daily database by pulling in all the constant data each time to show the current state of the products.
Some data, like type, can’t be parsed and must be pulled in from the previous state each time, making the logic too complex, which is where the real issue lies.

And it’s not a problem to create a new table manually, but it’s much more convenient to clone the first one and remove unnecessary columns. Especially since I manually set my column labels in Cyrillic and ID with Latin characters.

  • I’ve to repeat it for manufacturers, sellers and may be some additional table with similar logic and will create similar table all the time.

Thanks for the explanation. Yes, I think I understand the motivation, and I agree there are cases when duplicating the structure of a table (or part of it) makes sense.

We do plan to add the ability to duplicate a table (as opposed to duplicating a view), I just don’t have an ETA for it yet.

1 Like

Thank you, it always great to have Ux improvements.

Just remembered another case then it was needed:
I was experimenting with some similar products data by creation additional columns making some calcs and fetching data from different tables.

I got one table at the beginning but built several different layouts out of it. All good but everytime I was importing same initial csv and tuning column names same way.

Ps: used grist to prepare shops data for transfers from PrestaShop to woocommerce to avoid complicated dB export and combining all data tables for import in grist. Worked great

1 Like