Hi there, I am trying really hard to use this product for what I need to do. I want to use the Lookups feature to summarize data in a table. Despite following the instructions from Coda I just cannot get it to work. What the heck am I doing wrong.
What the heck am I missing? There must be a couple of key pieces of information missing from the help article I think. Why does their middle tile have a little row of boxes at the end?
I asked Support and they told me to go ask the Community. Thanks so much in advance for your assistance.
Itâs hard to assist you with only screenshots to go on. Itâs always much quicker and easier for us to help when we can review the schema and formulas in a dummy doc.
That said, it looks like your second argument Summary of tables close.Trade Type is a list of rows, rather than a single row.
Summary of tables close looks to be a table, which is a list of rows. The appended .Trade Type indicates which column to return for that list.
Probably whatâs happening (canât tell, cuz no dummy docđ) is that your table is named Summary of tables close and the column has the same name Summary of tables close, and you are selecting the wrong one in the formula editor. The column version holds a Select value which is a single row, which is what the formula parameter calls for, but you are likely entering into the formula the table version, which is a list of rows, which is not what the formula parameter calls for.
So try building your formula again while being picky about which value youâre choosing in the formula editor â the table or the column.
Support have been great in the past but now they are sending a stock response directing me to ask the community instead. Donât know why⌠maybe they are short on resources so thatâs all they can manage.
Hi Ander,
I am not sure how to set the formula to pick the Select value rather than a list of rows. The source column (âTrade Typeâ in the Table âSummary table of closed tradesâ) is formatted as a âSelectâ column. Do I need to format the source column in a different way?
In the source table there are multiple rows with each of the âTrade Typesâ and I want to summarize how many of each type, and create performance stats on each âTrade Typeâ.
Why does the source table in the example have little arrows in the top right of each cell? My source column doesnât have those. Could that be a reason why my formula is not working?
On the table Summary table of closed trades, you should also change the Display column to a column that holds unique values. Right now that column is filled with duplicate values, which is likely to cause you problems down the road, if it isnât already.
OK, good suggestion. I have changed the display column to the first column which is the âIDâ.
Should all display columns only contain unique values? Could that be why my document is so slow and often freezes up or spends minutes âSyncingâ. If so, I probably have the completely wrong structure for my document as it is tied together by the trade âIDâ and I have lots of multiple entries for the same ID in most of my tables.
Each row has a unique value under the hood, thatâs how the code base keeps track of them. Human users arenât required to designate row names (the Display column) with unique values. But you should. It will make your schema much more powerful and scalable, and prevent a lot of headaches and hair pulling.
No idea what might be causing performance issues.
In a doc like this that tracks transactions, I would definitely set the Display column of every table to a unique value. With a doc this built out, that could be quite an involved proposition, or not so much, just depends on current schema, which I didnât review.
Thank you so much Ander. That seems like a key piece of information that I did not pick anywhere along the way. Probably any database person that would be an obvious baseline piece of information. I do not have a coding or database background (although I am learning quickly) so that is really helpful.
I suspect the ID issue could be behind my performance issues so I will introduce row IDs and see if that helps. My husband is in the process of setting a database on Azure Data Studio and Jupyter Notebooks for me to migrate to because of the performance issues I have been experiencing.
Honestly, those are probably user-derived. Codaâs performance nowadays is remarkably good.
You probably just need to refactor your doc to implement best practices for schema, formulas, etc. Refactoring is a normal part of the development process, and nothing to be discouraged about. Iâve refactored some serious docs. Heck, Coda is right now refactoring a massive chunk of their entire code base! If your husband codes you a custom solution, he will also have to refactor that from time to time.
You know whatâs best for you, but I thought your doc looked pretty cool based on what little I reviewed, and I think you should not throw in the towel on Coda so soon!
Thanks Ander. I have spent a bunch of time refactoring as per the recommendations to increase performance. I didnât make a whole lot of difference to be honest. I did not know anything about the requirement to make sure that display columns do not contain duplicates. It makes sense from a database perspectiveâŚand a person like me with a no-code backgroud would have no way of intuitively knowing that. Why doesnât Coda return an error is you try to duplicate values in a display column?
Codaâs performance nowadays is remarkably good.