# Posts Tagged dax

### PowerPivot DAX Session Notes 2 – Previous Row

Posted by Gavin Russell-Rockliff in PowerPivot Ramblings on September 23, 2010

**previous row**of data within the PowerPivot model.

**opening position**at a point in time, and when the future actually closed, a second row would come through with the

**closing position**. The

**profit**made would be the difference between the opening position and the closing position.

**Previous Date**that applies to this particular Client Code.

**Value**at that point in time.

**Profit**is then simply Current Value – Previous Value for CLOSE rows.

=CALCULATE(MAX(Table1[Date]), (FILTER(Table1, EARLIER(Table1[Code])=Table1[Code] && EARLIER(Table1[Date])>Table1[Date])))

*Note: I’m still coming to grips with the EARLIER function, seems to work semantically the same as an INNER join… will hopefully post a better explanation when I understand some more…*

2. Using similar thinking, I could then join back to [Table1] and return the Value at the point in time established in the previous step.

*(I would love any feedback if it’s possible to merge this with the previous step, may be more efficient)*

=CALCULATE(SUM(Table1[Value]), (FILTER(Table1, EARLIER(Table1[Code])=Table1[Code] && EARLIER(Table1[DatePrevious])=Table1[Date])))

3. Finally, Profit is then just the difference between the current value and the previous value for the CLOSE rows.

=if(Table1[Position]="CLOSE", Table1[Value]-Table1[ValuePrevious], BLANK())

Results in the table below.

### PowerPivot DAX Session Notes 1 – Dates

Posted by Gavin Russell-Rockliff in PowerPivot Ramblings on September 13, 2010

**Dates**

**MonthName**(<date>) function.

*(and yes, I only learnt about this this morning, always more to learn)*

**sort order**of months.

*(and oddly enough this does confuse end users!)*

*(But 02-February is also not so user friendly on reports!)*

### SQL PASS: DAX, the language of PowerPivot

Posted by Gavin Russell-Rockliff in #sqlpass 2009 on November 6, 2009

PowerPivot, the topic that has been getting all the big attention here at PASS, has introduced ‘yet another’ expression language to define calculations. So, introducing DAX, **D**ata **A**nalysis e**X**pressions.

The idea behind this language is to provide OLAP type query functionality to the Excel end user. So the basic syntax looks and feels exactly like standard Excel functions. A set of Excel functions have been implemented (80 in total), with additional functions from the Vertipaq engine to allow OLAP functionality.

**Ed Note**: The additional functions in DAX actually come directly from the VertiPaq engine. Meaning that it is not a wrapper for MDX, it is actually the language used to define and execute the calculation within the engine.

DAX can be used in two places

- Calculated Columns
- Similar to creating measures in fact tables, or in the DSV in SSAS. Basically used for
**line-by-line**calculations. These values are calculated and stored at design time, and not recalculated at execution time.

- Similar to creating measures in fact tables, or in the DSV in SSAS. Basically used for
- Measures
- Similar to Calculations in SSAS. Calculated at run time, in the context of the current pivot table or query. Best place to define
**ratios**or custom aggregations that don’t make sense in a line-by-line method.

- Similar to Calculations in SSAS. Calculated at run time, in the context of the current pivot table or query. Best place to define

IMHO, the single most important aspect of this language is the underlying relationships defined within the PowerPivot model. As most calculations require some form of navigation between tables, whether it be date calculations or aggregations over groups.

The basic groups of functions that are supported include:

- Excel Functions
- Relationships
- Aggregation
- Table Functions
- Time Intelligence

The Time Intelligence ones are by far the most fun ones for me. it is possible to define MDX-type calculations including Year on Year growth, Period to Date and Parallel Period navigation. A bit of a different model though, as the “time dimension” is assumed based on date fields. Only limitation is that it assumes calendar time.

e.g. YOY Growth looks like

Fact([Sales]) – Fact([Sales])(DateAdd(Time[Date], -1, YEAR)

Overall impression is very positive. Full descriptions available at http://blogs.msdn.com/powerpivot/archive/2009/10/01/introduction-to-data-analysis-expressions-dax-in-gemini.aspx