You would think this works, but since Table.Nth(i) returns an error when i > Table.Count()—rather than returning Blank—it breaks. If it returned Blank not only could this formula work, but it would also likely allow more efficient lookups, e.g.
I want to use thisTable.Nth() to look up the previous row. However, the first row will not have a previous row. I’d like to know how to access that previous row
Yeah, I know how to do a running total with thisRow.RowId() but I want to do it with Nth, that’s why I’m asking if there is a way to get Nth to return blank (not error) if it fails a lookup.
Hi Connor, why would the index ever be out of range if you are finding thisRow in thisTable? Except for the first row, I suppose, which has no previous.
But maybe this is what you are looking for? But you are right, it is not as elegant as Nth() returning a blank value rather than an error.
If for whatever reason I thought that index might be higher or lower than the range, I would have to include that in my if statement. Eg, If(index<=1 || index>Count(thisTable), ...
Note that this index is the manual order of the rows and does not reflect either RowID or any filter/sort AFAIK.
As per OP’s original intent, can anyone confirm whether this is actually more efficient than the filter/slice version of the running total formula? Does it make any difference?
Yeah, this specific lookup is likely not more efficient. When I’m back at my computer I’ll have to look back at what I thought would be more efficient.
Yes, an if statement solves the problem at the price of elegance.
One way this could work is Nth could have a second parameter which is what it returns if the index is not found. E.g. List(1,2,3,4).Nth(5, false) would return false.