Hey all,
to make a good use of cross-doc feature, I created views on my source table. This way, I can choose which column my target documents will get, and also I can filter out unnecessary rows.
But, when doing this, the relation columns don’t work anymore. All values are greyed and I get a “table not found” suggesting me to create the table. Well, a view of this table is just above, supposedly with all proper information to be identifiable.
If I import the original tables all works well, but that defeats the purpose of the filtering of the unecessary data. Am I missing something there?
Thx in advance for your help 
Laurent
Hey @Laurent_Auneau,
This is indeed a limitation of Cross-doc. For references to work you have to import the base table of that referenced table, which is not ideal.
You have two options:
-
Instead of references, cross-doc row IDs, and then on the receiving side restore those references through a formula. I’m talking about all of this in my old video Cross-doc Best Practices
-
Use my pack, Sync Tables Pro, which is a cross-doc replacement built with all these issues in mind. STP will actually force you to sync views not base tables, and actually preserve such references.
1 Like
OK, so I manually added a column and did a lookup in the other synced table. It works, also it’s quite ugly…
[XDoc Projet].Filter(Nom=thisRow.Row.Projet.ToText())
You suggest a better way by using rowIDs, right?
Yes, it’s better to not depend on what is your current choice for the display column (i.e. what is used for that ToText()). Always better to match on the identifier that’s guaranteed to be unique, too — RowID or UID.
1 Like
Yup, will go for that. With 2 ways-sync and native support, it feels like a safe choice.
I was willing to support you though, so I went to your patreon and bought the big cake
Keep up!
1 Like
Just hit a big caveat with 2-ways sync: as linked relations are being reconstructed using a formula with rowID, you can’t change their values by selecting from a combo, you have to use rowIDs.
Is there an ergonomic way to let users change them?
Also, let’s push it to the end, I have linked relations (1:many), and that feature works really well for some use cases…
Oh man ;(
2WS doesn’t support … lists?
Is there a tipbox to speed up row-level and overall better native cross doc support?
1 Like
In the end, --it works fine-- if you import base tables. EDIT: actually not that much. The 1:many relation is lost. When you have multiple contacts in a single company, in the destination doc you cannot add or remove them directly from the company table as it is possible in the source document, you need to go to the contacts table and find them one by one to add them to the company.
Yet another EDIT.
Things get MUCH simpler if you don’t enforce a type in the calculated columns.
As instance, if you’re OK with letting go the “linked relation”, then you can have a text column with a formula pulling one or more references. These references will be properly typed!
But now all my data is copied on the destination doc (all lines and all columns), and in the source doc I can’t properly choose what my people see when hovering over one of those element (could be interesting to upgrade that feature by the way, a “set as display table” maybe?).
So I can see one, big, much needed improvement on Coda’s side: to support importing of views without losing relations. Not sure what’s the issue as to why it’s not already here…
Of course, row-level access privileges would be (much) better, as it would lower the amount of data transfered. A little formula on the token maybe? Any plan on this in a foreseeable future @coda team?
1 Like
