Well, one reason is this:
I agree that the ADC abbreviation sounds better than STP.
Naming is hard.
2 Likes
Hey all!
A little update on the project — it’s very very around the corner. As some last days changes I wanted to do some future-facing improvements and cleanups, and didn’t make it in time for the platform launch.
Now I’m working 20 hours a day to deliver another project — a pack for the Packathon whose deadline is in two days. The project I’m building for the Packathon is perhaps even more epic, and I’m nearing its completion. After I’m relaxed about that, I’ll do the final push on Sync Tables Pro — this week already!
5 Likes
@Paul_Danyliuk, amazing work as always - can’t wait to try it out. Also, my vote goes for ‘Sync Tables Pro’ if that hasn’t already been decided 
.
2 Likes
STP was my favorite band growing up, so i vote yes on STP.
3 Likes
in my younger days we would put STP oil in the engines of our older cars to make them run smoother, faster, and better.
it made an old beat-up clunker purr like kitten, growl like a lion and run like a cheetah!
very like your pack, @Paul_Danyliuk 
max
2 Likes
Another sneak peak:
Teachers are synced from doc A
Students are synced from doc B
Classes are synced from doc C where the Classes table references the syncs of Teachers and Students.
Needless to say, all are views and not base tables.
My pack is capable of resolving and/or manually remapping references so that nothing is broken, no matter the sync path.
3 Likes
Another fresh improvement:
Each export view can now use a different column to specify its row-level read rules.
And with a shorthand [read:*] there’s no need for the rule column at all — everyone can read all rows
Being free to design my pack as I wish is so liberating! I can make it so much flexible!
3 Likes
Psssst 
Yet to record instructional videos because otherwise you won’t be able to set it up.
2 Likes
And here are the vids.
And I still need to make the docs doc before I make an announcement, but you can try this out already.
P.S. Also the Union tables are coming a bit later. I want to somewhat redesign the query language I’m using and make it more future-proof.
2 Likes
hi @Paul_Danyliuk ,
Great to see the pack in the gallery, and I am going thorough the vids now.
A couple of things on my mind:
- Is there a current or planned way to make this play nice with cross-doc actions?
- I currently have a giant web of docs (Employees, Contracts, Payments, Designs… that sort of thing) each providing one or more tables that are cross doc’ed out into some of the others. If I want switch to Sync Tables Pro, is my only option really to re-design the whole pile? Any tricks to lessen the pain ?
Hey!
Re actions, I plan to add my own actions to the pack, following the same security framework with row-level rules and secret tokens.
In my initial iterations I had STP designed to work with cross-doc actions (e.g. the Sync Path property would list row URLs ready to use with an EditRow/AddRow formula etc). But then I decided against it. The reason is: mixing two security systems — row-level based in STP and connection-based in CD — could very easily lead to security holes. Imagine a situation where you put effort into securing your view for STP so that a person only has access to limited rows — but then you give them an action to update that table and the person just rewrites all __read column values to gain access to all of it. Remember that in CD you cannot limit access more granularly than on the whole base table level.
That said, nothing prevents you from installing CD and using actions with a constructed row URL, if you’re okay with the risk.
Re switching, yeah, unfortunately that’s your only option 
There’s no known way to replace tables easily.
Hi Paul
This pack would be beneficial for my business
I tried it but I received this message >
Hey @David_Mendoza, I can’t see the logs or debug this remotely. Can we schedule some time so that I try to debug this on the call? I’ll DM you now.
Could be temporary hiccups though — does this always happen?
Hey Paul.
Do you have any timeline for these features:
Roadmap for the next features:
• Merge tables — Combine data from multiple sources into a single sync table.
• Actions — Add, edit, and delete row(s) with row-level permission rules.
• Table mirroring — A way to sync two or more tables that are editable on both sides.
These will be some killer options to have, and solve quite a few complicated and not optimal cross-doc situations we have 
Cant wait for those features to go live so we can fully switch to Sync Tables Plus, only pain will be re-working old docs that currently use cross-doc 
p.s. About actions, if we use Merge Tables (for example 3 into 1) will those actions still work, for example if I update one row in resulting table would corresponding row in one of 3 source tables be updated or would actions only work for 1:1 sync? Do you know if something like that would technically be possible to implement
No concrete timeline but union tables are on the-flipchart-before-my-eyes-list already 
It’s just that there are always some urgent distractions.
Hopefully this week?..
Re Actions, those will work a lot like Cross-doc Actions — separately from sync tables. You won’t even have to sync the table at all — as long as you’ll have the row URL and whatever you submit passes security checks (the secret token matches against the rules) it will go through.
Each row is identified by the combination of Doc ID, Table ID (or View ID), and Row ID. Then, it doesn’t matter how, if at all, it comes through to your doc. Union tables will preserve those “CUIDs” (combined unique IDs). When you run an e.g. Edit Row on a given row, it will look up __edit rules for that row on the target table and see whether your secret passphrase is allowed for applying an edit, and it will either go through or not. Ultimately I’ll extend this mechanism with being able to specify which columns can and cannot be written to, and who knows, maybe validation rules too?
This may take a bit more time to implement right — it has to be designed right because of security implications. Regular Cross-doc Actions are not really secure: they rely on a token that allows write access to a table (and in practice, you would just create an allow-all token), allowing anyone with that connection to not just add but also edit and delete rows in that table or the whole doc, or any docs used by that user if the token wasn’t properly restricted (and it usually isn’t). STP does it differently by design right away, it reuses one allow-all connection (and that’s okay) and the security is based on secret passphrases.
1 Like
I have tried to install your pack on a trial, but i cant load any tables when i go into the pack. Pls see the attached screenshot below. What should i do?
Oh hey @yscias, terribly sorry for overlooking your question.
That’s a strange error and a non-descriptive one unfortunately. If this is still relevant for you, please DM me or write at paul@codatricks.com and we’ll book a call where I’ll try to troubleshoot it
@Paul_Danyliuk This is a critical tool, thank you for making it! What are your current plans for updates?
1 Like
I keep getting no results found on the trial I have Coda Pro not Team is that affecting why no tables are showing up?
Well, at least the connection works, so that’s not the problem.
The pack requires you to specifically make VIEWS whose names start with [OUT]. This is how you signal to the pack that this data is explicitly made “exportable” — the pack will not read from other tables or views from that doc.
@yscias — in your case there could be some hiccups with the connection you’re using for the pack. Another client had the same issue and the way to fix this was to… delete the connection and create a new one like this:
