This is a great feature. The only issue is I also need to be able to sync links between tables. Let’s say a user table and an address table. If I make both of them a common data set and then import them both into a new base the links are copied as plan text.
Please elaborate. It’s not clear what you mean.
I have Table1 and Table2 in Base_A and they have a linked field. I can share both tables via the common data function. If i then import Table1 and Table2 into Base_B the linked fields are imported as text fields. all linked records are lost between Table1 and Table2. Preferably if both tables are in a common table then the link is maintained. (my guess is that the common tables are a data set that lives outside of the bases its linked to)
I’m creating a trip planner and I want common items like destinations, locations etc to be synced between multiple bases. because of how the common data function works the field linking these tables is lost. I end up manually coping data between the bases, or deleting them and copying them from my originating base. (I know i could write a script to ‘sync’ data but without a way of knowing the parent and then child IDs of the columns you run the risk of data corruption. )
Actually what would be better, and perhaps easier to create is the ability to link tables between bases. What I would love to be able to do is create a table in one base, link to a view of it from another base, and add fields that are unique to that second base. Example… —
- The common base table Destinations would have the fields: name, location, map link, photo, etc
- In Base_Plan_A there is a link to Destinations, but the fields, Visited, Would like to Visit, and Visit date are unique to Base_Plan_A.
If in Base_Plan_A name is changed it is updated in the main table and all other child tables.
I feel this could easily be accomplished by having a one-to-one relationship in Base_plan_A to the common base’s table and extending the data set. It would just require a view to combining the columns from the two bases.
This is the designed behavior. Exactly.
Sorry, we have no such plans.
As said above, syncing between multiple bases is not possible and will not be possible for the foreseeable future.
But I still don’t understand why this is required. Common datasets (CDS), which permit the sync of one table into multiple other bases, seem IMHO to meet your requirements. Here’s what I would do:
- Create a group for your trip planners
- Create a base in this group and put all your “common items like destinations, locations etc” in one table
- Publish this table as a common dataset
- Create one or more bases for your trip planners (if you create these bases in another group, you have to share the CDS with this group)
- Import the common dataset into this base
Now you can link to the items in the imported table.
I would agree that if my data was fairly simple this would work, but it isn’t… Attractions table, ~400 records, links out to two other tables, Locations, and Media. If I use Common data sets those links are lost, even if the related tables are shared. I could move Locations to a select column, but I then lose flexibility as Locations are linked to Dining and Attractions. (I use this in my custom interface for showing Dining and Attraction options in a single location). Media is a large one-to-many relationship as a single video can be linked to and is linked to 30 Dinning items. Dining Items may also have more than one media item.
I do realize that my use case is probably more edge than others out there. Also if I have to could mgrate all the data from SeaTable to straight Prostgress SQL tables. – Although I don’t want to write middleware, I like using your APIs… 
Do you track a parent ID in your common datasets or is the updates based on the Name field… If the first is true is there a way to access that ID via python scripts?
Every record (row) have a unique _id field. The _id is a UUID. When you sync a table to another table via common dataset, the _id is not changed.
