Hey,
I just want to us the last column, so sum all previous columns, using a formula
I can use the formula Sum(A,B,C).
This works, however I could have a large number of columns or add new ones.
So I want to specify a range of columns, with something like Sum(A:C).
This is so basic. It’s so basic infact, if you ask coda AI, it gives you the range formula!!
Is there anyway to specify a range of columns in coda?
And if not why not.
Thanks,
Ian
This is basic in Sheets where the choice to lay out values of the same nature horizontally (e.g. sales for each month) is your choice.
In Coda, columns are NOT used to spread out a collection of such values. It is against the database design. Separate columns are separate properties of a row, like a Sale Date, a Product, and an Amount. “March”, “April”, “May” etc are not properties of a row but values on a property Sales Month, hence it must be represented with values on a column and not in many columns.
Give me the doc that you’re trying to solve this for, I’ll show by example what I mean.
P.S. Coda AI doesn’t know the coda formula language that well; it makes up stuff taking bits from Sheets too.
Hey, working through a table like this on my own, it might be an excel vs coda/database debate here… (Admittedly I’m not familiar with all codas formulas yet)
But what I’d suggest (and it’s how I’m making a change to one of my tables…) is you make one table with the values you’re wanting to add up (i.e. personnel, travel, etc.) then add that table as a look up column in your table with the values you’re trying to capture in their own rows (i.e. a row for each year of personnel etc.)
Then in that original table you can add a column that adds up all those rows in the second table…
Hope that made sense!
Hey, I understand that coda uses a column as a unit.
However specifying a column range is still:
Can anyone give me a reason coda haven’t implemented this?
No, because columns are technically not ordered. Those are a set of properties, not a list. It’s in one’s head that e.g. Last Name goes after First Name, but in reality those are just two properties that can appear in whatever order on a record.
Think of the many views that you can create on the table, and how they can have a different visibility and order of columns.
Only if your brain got hardwired to working with spreadsheets and you’re unwilling to give up that way. It is much more useful to model the data the database (fact table) way and work off that. Even Excel/Sheets will force you to use fact tables structure if you want to do pivot tables — think of databases as exclusively pivot tables stuff.
Again, please give me an example where you think this is valid and useful, and I’ll prove you wrong.
If you’re using columns as different values on one dimension (e.g. sales in store 1, store 2 etc, and you want the total sales per product) then you need to rearchitect the table.
If you’re actually using columns for properties e.g. Price, Shipping Cost, Handling Cost, Tax etc, and you want a total of that, then you need to explicitly write in your formula which properties you want to add together. There is no guarantee that those individual property columns will stay together in a continuous range for you to add together. You’re just going to have a trouble one day.
Sorry Paul but you’ve really drank the cool aid on this.
This sounds a little arrogant TBH.
Again, please give me an example where you think this is valid and useful, and I’ll prove you wrong.
What I’m trying to so is use formulas to calculate different budget items. I have to put them in separate columns, because I only get 1 formula per column. Then I want to sum each item top get a total spend. Very simple. Very basic.
Ian
Hi @Ian_T,
There are some fundamental differences between Tables and Spreadsheets. With those differences in mind, you can structure your data a bit different in each system to fully take advantage of each one’s strengths. You can also create more work for yourself if you try to stamp in the patterns from the other one.
Here is a great blog article covering the differences in Tables and Spreadsheets and why Coda chose to go the table route.
For me personally, if I find myself adding columns that repeat a formula or process, that’s a good indicator that I can actually turn that data into rows instead. I would add a “Category” column and then tag each row with the category instead of creating a column for every category.
Once data is in rows and tagged, you can really start to take advantage of Coda’s table connections and Filter() formula to get anything you want from it, and much more efficiently.
Here’s a setup where the Categories for a budget are assigned per row and then rolled up into the Category table for totals. With this setup, I can add categories whenever I want and the formulas and options just keep working. There is no more needing to worry about what range to choose or having to adjust formulas if things change.
Give this a look and let me know what you think.
This articles was very helpful to me, when I was trying to break myself of rolling totals across the bottom of my spreadsheets in Coda…How to Coda a Rolling Total?. Using FormulaMap() and Sequence() to… | by Christiaan Huizer | Medium
Thanks @BenLee.
I’m not quite sure we’re doing the same thing.
For my spreadsheet, each of the budget items, are themselves calculated by formulas.
For example the cost of Materials would be, HeadCount X CostOfComputer.
This necessitates, those formulas to be in their own column.
What am I missing?
I’ve included a simplified version of what I am doing here:
https://coda.io/d/_dpVJ3BeHuxy/Budget-Example-DM_suwHO#_lu7xS
You’re still doing things in columns instead of rows.
You should create a “Projects” table, then create a “Tracker” table. Any item you add in the Tracker table can be assigned to a particular project. Then it’s much easier to filter and total items.
Hi Ian
Talking from personal experience - it took me about a year to get the spreadsheet model out of my head, and replace it with Coda modelS. And I haven’t looked back since.
And I specifically use the plural, because once you understand the underlying Coda model, you quickly see that it lends itself to very different useful models - to manage lists and meetings and financials and projects and wikis and policy and procedures manuals and many, many more. Each of them takes some unique aspect of Coda and molds it to a purpose.
Regards
Piet
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.