How do I de-refernce a value from the row returned with MAXROW()?

Just thinking this must be simpler.

I am cycling through a set of Actions to insert a computed number of Teams. So, I know the number of teams to add and to determine if I have inserted the correct number, I am tracking a Team # value. Once this Team # matches my expected number of team to be inserted, I know I am done.

With each iteration, I want to grab the Team row with the maximum Team # and then simply add 1 to it.

I can get the maximum Team # row like so:

MAXROW("Teams", "Team #", [Challenge] = [_THISROW].[Challenge ID])

This returns a row reference to that Team row. Is there some straight-forward way to dereference the Team # value from row reference?

So far the best I could figure out is that I need to do the below but it seem unnecessarily repetitive.

ANY(SELECT(Teams[Team #], 
     [Team ID] = MAXROW("Teams", "Team #", [Challenge] = [_THISROW].[Challenge ID]))
) + 1
0 10 350
10 REPLIES 10

Steve
Participant V

Nope.

I agree with your observation to be able to do something like:

(Function Ref Result).[Ref table column]

The funny thing is that the parser already supports this!!

And I donโ€™t think it would take much to then include:

[Ref Column].[Ref Column].[Ref Column]...[Column_I_Want]

I fairly certain this construct is supported in the source code used to build out the AppSheet platform. Itโ€™s just a matter of tapping into it from expressions.

In that it doesnโ€™t complain about it. That doesnโ€™t mean it supports it. There are at least several constructs the parser allows but doesnโ€™t support. For instance:

table[column1].[column2]

Not supported, but allowed by the parser. Equivalent to:

[column1].[column2]

In fact, the table name there is completely ignored. You could put literally any word there, table name or not.

Yeah thatโ€™s really what I meant.

Chaining of refs is already here. But it wonโ€™t work from a MAXROW() (It has to be a legit ref (or maybe enum-ref would work).

Iโ€™ve not played with ref chaining much - I always forget itโ€™s a thing

Praveenโ€™s answer is classic (^_^)

Yeah, we need the ability to deference from any singularly returned Key value.

Definitely will save a lot of coding effort to be able to utilize such a capability.

Awesome! I have a use case right now to try it out.

Been out since Nov? Iโ€™m not even going to think of all the work around code and extra columns I added in the past several months simply because I THOUGHT I couldnโ€™t chain references!! I know there were several.

Oh well, cโ€™est la vie! โ€ฆ and software development!!

Oh manโ€ฆ for real

3X_a_d_ad3e9ac0a27a3a582b45269cfe7094a4f2789d5c.gif

EVERY time I come back to the thought that we can do this now, Iโ€™m likeโ€ฆ ugh. SOOOOO much updating work to be done.

Top Labels in this Space