I’ve done a lot of really complex filters in the past but I’ve never had as much trouble as I’m having with a client doc. Doing final testing right now and I can’t even test because every page of the doc just “hangs”.
I have a user table and different user types. Most of the data is all coming from one table just filtered differently. If a user is of type Admin then they will be allowed to see any records but if a user has a different user type, then the filter is based on their name being in a field. I know the filters work. They were working just fine until the last week in final testing and now every page if I sign in with any id other than an Admin ID it just breaks.
I can’t share the doc due to the data in it. But basically I filter based on date >= today and then different checkboxes and the last item in the filter is an if statement looking at the current user and their type in the user table.
I started seeing problems when the Filter Bar was introduced. I do have some views with the filter bar turned on and other views with it turned off. I’m wondering if somehow this new filter bar is messing up the filter on other views or something.
I’ve spent 6 hours today trying to get any page to load and all I do is click wait. Tried reloading the doc multiple times. For the Admin users, no problems at all and they see up to 2,000 records of an 8,000 record table. But users who might only have 1 - 5 items visible based on the filters can’t get their pages to load.
Have you tried the debug calculations timer?
It would let you see what specifically is consuming the processing resources
Can’t say much without seeing the doc though.
As a part of my Coda consultancy I’m fixing slow docs and I’m pretty good at it We could arrange a 1-on-1 quick rescue session sometime in my afternoon (I’m in EET). Please DM or email me at firstname.lastname@example.org if you’re interested.
Yes but most of the time it doesn’t even say calculating so I can’t access that feature.
You can still access that feature at any time - head to the Doc Map settings and then navigate to the snowman menu at the top right of your screen
Start measuring calculations, then start navigating the doc normally or pressing buttons, adding rows, etc that cause the slowdowns. That will help you begin to identify what is going on
Another good resource for you is this article put out by coda and this doc put out by Ben Lee
If you still need some assistance, we at SimplaDocs have helped dozens of clients optimize slow docs, restructure laggy docs, and map out paths forward to create docs that can scale for years.
Give us a ring at email@example.com if you need some more serious help! Happy to help you get to the bottom of what’s going on.
Great info. Thanks. If I had any profit on this job I’d be happy to hire you to look at it but I’m doing this job at a low rate just to get back into the consulting business after a 15 year career gap!
Question though. If I’m looking up the current user and comparing to see if a field in this table should be visible is it better to just do that comparison in the filter or would it be faster to put that test into a column in the table? Example: Column name: Visible formula in column would then be a filter of the user table and a test to see if that user = this row’s user. Then just do the filter formula on visible. Not sure if that would speed it up or slow it down.
hey @Scott_Collier-Weir or @Paul_Danyliuk QUESTION: is it better to put a column in a table and have that column calculate whether or not a user should be able to see a row so that in all the views of the table the filter just has to test for visibility among other things rather than writing the filter for each view to restrict the row?
Had Coda Support online today to look at my doc. Here’s the absurd thing we are seeing.
If I put a formula say in this case it was a switchif testing to see if a user was a Linguist, Client, Admin, etc. the filter formula works perfectly until a user who hasn’t been added to the admin table crops up.
Here’s the odd thing. I can write the formula and put it in the filter. Formula works except for client not in user table. BUT. If I take that exact same test formula to see if the user exists and put it on the canvas as a canvas formula, then have the filter call that canvas formula as it’s test, then it works.
Same exact formula. But when that formula is in the filter SwitchIf statement it throws an error for the user who is not in the table when referencing the .column that you want to compare.
What makes no sense is, calling the formula on the canvas is doing the same exact evaluation and passing but inside the filter formula it’s failing. Odd. Coda is going to put this in to see if it’s a bug as they agreed that they saw nothing wrong with the formula and were baffled that it threw the error.
I am sorry, I cannot visualize the situation from the description. I still need to see the doc Then it usually takes under a minute for me to see the issue.
Totally understand re budget limitations. Still, feel free to share the doc privately with firstname.lastname@example.org and maybe record a loom or something (where for me to look). When I have a spare minute I’ll take a quick look. Like 4 out of 5 times, there could be some very trivial and fundamental thing that’s the culprit.