Forum Discussion
Distinct Count with value in same table
Another thing you may want to try then is instead of appending the two data tables, merge them side by side.
So intead of your original table, you end up with something like this:
CODE PREV_STATE CUR_STATE CHANGED 1015 A A TRUE 1016 A B FALSE 1017 B B TRUE If whatever index you're using for each row stays the same between days, this may be a better way to store your data. Be sure to check my previous reply for DAX code to solve your original problem
Cmcmahan, I did it, but I lost the another columns, I want to keep them (in the example bottom I didn´t show them).
PD: I suggested Power Query for better performance, (I think). If there is another way to achieve this without impacting performance, feel free to help me.
Resident RockstarSo the answer depends on what data is in those other columns. If it's data that would make sense to aggregate (either through COUNT, SUM, AVERAGE, etc) you can add it in the Group By wizard, or with the advanced Power Query editor like so:
#"Grouped Rows1" = Table.Group(#"Changed Type", {"Code", "State"}, {{"Result", each Table.RowCount(_), type number}, {"Highest Price", each List.Max([Price]), type text}})
If you do not have data you want aggregated, you need to create a separate table and then do the Group By on that like before.
The problem with Power Query is that there isn't a way to dynamically copy another table. When you press copy, it copies a snapshot of the current table, so if you upload new data, you have to copy the table over again, or set the new table to load from the same data source.
I'm still not sure why you would strongly prefer Power Query instead of DAX for this. Creating a custom summary table is incredibly easy in DAX, and I feel like if you have millions of rows of data, having to copy and then do Power Query transformations on the second table seems like a ton of extra processing.
I tried to search and see if there are performance differences for Power Query vs DAX, and can't find any information on that. And since DAX is built to create measures exactly like this, I would use that.