I have a relationship between a Table1 table and a Calendar table.
When I try to use a DAX expression using fields from these table, I get this error:
The expression referenced a relationship between Table1[DateKey] and CalendarTable[DateKey], which does not hold any data because it needs to be recalculated.
Any ideas of why this is happening?
This is happening because your excel workbook (and Power Pivot) is most likely in manual calculation mode. Go to Power Pivot -> Design Tab -> Calculation Options -> "Automatic Calculation Mode". That will allow all your DAX fields to recalculate and the issue should be corrected.
Related
I have sums of table columns as measures but for multiple tables. I combined them as sums of measures. On the pivot sheet i want to drill trough but i can't because it belongs to only one table. Are there any better solution for measure combinations? Thank You!
I assume by the "drill through" you mean what happens when you double click a cell in the pivot. Also, I assume that you've built a star schema with most of the measures in the centre table, and all the tables are keyed together.
You're not going to like this one, but the drill through is determined by the table you associate the measure with, and the records of just that table are returned; so the drill through is actually fairly limited. Each measure can be associated with any table, not just the one it uses, so if there is one table you want to drill into, you could associate all the measures with that.
But that's probably not really what you want. The only solution I've found is to create a pivot with the same slicer dependencies that contains all the fields you want on the drill down, and only those ones - so you've got a detail version of the main table on a different sheet. The other thing you might consider is shutting down the drill down functionality by creating an empty table, and associating all the measures with that.
Is it possible to create a derived table in PowerPivot from a DAX query? For example, the SUMMARIZE function returns a table. But, I haven't found a way to create a table based upon the value returned by this function.
If you have Excel 2013 it is possible though not as easy as the calculated tables #greggyb refers to. This article explains how:
http://www.sqlbi.com/articles/linkback-tables-in-powerpivot-for-excel-2013
Currently the only product that allows calculated tables is Power BI Desktop. Power Pivot for Excel 2016 will likely get this in an update at some point. I can't speak to Power Pivot for previous versions of Excel.
I have a simple PowerPivot model with 2 tables:
DimDate & UserTransactions
I have defined a relationship on [Date] between the two tables.
Now, if I create multiple pivot charts in Excel based on both DimDate and UserTransactions (Axis comes from DimDate, Values come from UserTransaction), and then I decide that I want to use a slicer or a timeline tied to DimDate, should I or should I not expect that selecting an item in the slicer/timeline will filter the pivot charts?
The behavior I am seeing is no, it does not by default act upon all pivot charts - to do so, you must right click the slicer, choose "Report Connections", and then place a checkmark on each Pivot Chart that you want associated with the slicer, and they all then react to the slicer selection. This implies that the slicer is acting upon the pivot chart, and not the PowerPivot model itself.
This isn't unreasonable, and in cases could be beneficial (if you don't want all pivots tied to one slicer).
However, on the other hand, this seems a bit dangerous in that it could be extremely easy in a large model to miss associating a slicer with all pivots. Also, it seems inconsistent with the following blog post, which implies that the slicer filtering *is acting upon the PowerPivot model itself, rather than individual pivot tables.
http://tinylizard.com/power-pivot-relationships/
But the most important understanding is that any filters applied to a
lookup table are also applied to related data tables. And, the
reverse is not true. That is where the direction really matters.
It does not matter why this filter is happening. If I have a
relationship between my Calendar table and Sales[SalesDate], it does
not matter “how” a filter got applied to the Calendar table so that
Calendar[Year]=2009… the impact is that the filter will also be
applied to the data table (Sales). It could be from a slicer. It
could be because you put Year on rows. It could be because you wrote
a CALCULATE(). Anything. But, the reverse is not true. A filter on
your Sales table has no impact on your Calendar table. Relationships
have direction.
So:
Is the behavior (that slicers are tied to individual pivot tables, and not tied to the powerpivot model) I am observing the correct (and only) behavior available? You cannot apply filtering at the model level, and therefore what is implied in that blog post is technically incorrect?
Or is there possibly an alternate approach that does support filtering at the model level?
I have a fact table that has a column with dates loaded from an MS Access source. The thing is, some of the values are NULL and the SSAS won't let me refer my DATE dimension to it.
Is it better to solve it at the SSIS stage or is there some solution at the SSAS?
Thank you very much for you help.
Best practice is not to have any NULL key (i.e. Dimension key) values in a Fact table.
Instead, create a MAX date in the Date dimension table (or an 'UnknownValue', -1 for instance) and key to that.
Sometimes it is undesirable for non-technical reasons to fix the nulls in the DSV or source system. In that case you can use the unknown member and null processing properties to work around this issue:
http://technet.microsoft.com/en-us/library/ms170707.aspx
I have done this when trying to highlight the data qualities problems or for fast prototyping purposes.
Each member of a hierarchy has a property "HideMemberIf". Setting this to "NoName", should hide the null values from the Dimension Browser and allow processing of the cube.
Also you could created Named Calculations in the Datamart View. The Named Calculation would use the ISNULL function, which can fill in values in place of nulls. Then of course build your Time Dimension off of these Named Calculations instead of the raw data fields.
Again, it's better not to have any nulls in your data altogether, but you can usually fix this inside the Cube.
I want to use an MDX drill through command but i also want to join it to some SQL tables as well.
that is there will be an Id in the fact table and not a lot of other data I want to join this on to another table or view and produce a report based on those ID's returned in the drill down.
Ideas?
MDX won't do this directly. The only way I can think of doing this would be to retrieve the recordset from the drillthrough (which can be done with ADO), load it into a temporary table and join it against whatever else you want in a query.
The other option is to widen the drillthrough (if the dimensions have the data you need) and get the fields from that. Note that SSAS2005+ can support multiple drillthrough actions.
This MSDN article has some code snippets that demonstrate working with record sets returned from a drillthrough.