Create a new table with aggregate value

[Laurent_PULCE]

Hello,

I start with AppSheet and I need help on this topic.

I will (extremly) simplify my case : I have a table with detailed data which structure is :

-[Date Time Issue] - DateTime - Key

-[Value] - Decimal 

-[TheDay] - Date - Date([Date Time Issue])

I want to get an additional table containing the SUM of [Value] per [TheDay] (To perform others kinds of reports etc..)

How can I achieve that ?

Thanks a lot for the help

[WillowMobileSys]

There are two approaches I can think of you could take:

1)  Simply add a Virtual Column to your existing table for the SUM.  This does mean some rows will get the same summed value but you also will not need to do anything to construct a table to get this value.  You can filter this table by [TheDay] to get a single unique row by the day and have the correct SUM value - i.e. it doesn't matter which row represents [TheDay].

2) Create a table with an ID and [TheDay] columns and then add a virtual column for the SUM of rows in Table#1 for [TheDay].  When a row is inserted into Table#1 use a set of actions on the Form Save behavior (or you could use a BOT) to check if a row exists in Table#2 for [TheDay].  If not add it.  The virtual column will automatically update the SUM value when any new rows are added to Table#1.  This approach might make the most sense if you expect there to be a lot of other Summary columns in the table.

I hope this helps!

[Laurent_PULCE]

Thanks a lot for your answer !!
I already use the first method which look like the most simple and and I get the right result in the field (with several lines obviously) but I don't know how to filter the table to get only a single line for being able to use it in charts etc...
Should I do that with a Slice ?
I will investigate the second option, even if I don't exactly know how to do it, I feel the concept.
Thanks again for your guidance

[martinlozano]

Just started with App Sheet and found myself with the same questions. Looks like option 2 is the most... scalable and efficient way to go, right? 

Have you had the chance to try it out? @Laurent_PULCE 

[Steve]

---

@martinlozano wrote:

Looks like option 2 is the most... scalable and efficient way to go, right? 

---

Correct.