The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredCompete to become Power BI Data Viz World Champion! First round ends August 18th. Get started.
Hello Community,
Really struggling with this one.
The scenario is as follows:
- Rpt #1 uses its own dataset.
- Rpt #2 uses the shared dataset from Rpt #1.
In both reports, I am calling the exact same fields from the exact same dataset.
In Rpt #1, the table visual renders instantly without any issues:
In Rpt #2, the table visual spins for about 20 seconds and then fails with the classic frustrating error:
The table visual is very simple.
It contains only the following:
- 10 simple fields: Year, Agent, Partner, Plan, Entity, Street, City, State, Zip & Phone
- And 1 simple measure, which counts the number of "Policies":
Additional notes;
- The table visual only contains 500+ records.
- The entire fact table being filtered only has 2,315 rows.
I have read many posts & blogs concerning this error, but none of the suggested causes or solutions seem to apply.
- I have other table visuals in the tens of thousands of records, which render without issues. (vs ~500 here)
- I have other table visuals with 20 columns, which render without issues. (vs. 10 here)
- I have other table visuals with 4 or more measures as columns, each one of them much more complex than this simple measure. (vs. 1 measure here)
- I have other table visuals which render in both a primary report (direct dataset), and secondary report (using shared dataset).
How is it possible that a simple table visual with very small data can instantly render in the primary report (direct dataset access) and fail in a secondary report (shared dataset access)? (I really don't want to redevelop this secondary report with its own dataset for multiple reasons, but am unfortunately now considering it.)
I am very confused.
Would appreciate any guidance.
Regards,
Nathan
Well, I'm guessing that I had a corrupted table visual in Rpt #2.
Hard to know for sure. I can only guess.
Taking the following steps fixed it in Rpt #2:
- Deleted the entire table visual.
- Created a brand new table visual.
- Added all the same fields back to the visual.
And magically, it works now.
I don't understand. It's the same type of visual. It's the same columns.
But I guess I don't need to understand. 🙂
Still, I am very grateful for your response.
Thanks for the feedback.
Sincerely,
Nathan
I'm glad you got it sorted out. Occasionally things just do get corrupted but I haven't seen that very frequently in Power BI recently.
As for your question about the "Live Connection", you've confirmed that it's not DirectQuery.
"Connected live to the Power BI dataset" typically shows up in the bottom right of the report view:
Clicking "Make changes to this model" pops up the same "DirectQuery is required" box that you showed.
That's pretty weird.
When you say a "shared dataset", is Rpt #2 a "thin report" that's live connected to the Rpt #1 dataset or is it a DirectQuery connection?
Regardless, you could try changing your measure to simply
DISTINCTCOUNT ( 'Fact D365'[PolicyNumber] )
I doubt the measure is the issue though. What dataset tables does each of the columns in your table visual come from? Are they all from the same 2,315 rows fact table?
Thanks for your response.
1) For Rpt #2, I believe it's a Live connection.
When I click "Transform data", it doesn't explicitly state the connection is live.
It just says "A DirectQuery connection is required".
(Is there a way to see "Live Connection" explicitly stated?)
Additionally, on the left pane, you can see that Rpt #2 only has access to:
- Report View
- Model View
Since it's using a shared dataset, it has no access to the "Table View".
2) I have replaced my original measure with your measure.
(I agree this should not make a difference, but I did it anyway.)
3) Below is the relevant part of the model for the data I am pulling into the table visual.
- Year comes from 'D Year'
- Agent comes from 'D Agent',
- Partner comes from 'D Partner' (renamed in this thread for security reasons).
- All the remaining fields come directly from 'Fact D365' (Plan, Entity, Street, City, State, Zip & Phone).
Regards,
Nathan
User | Count |
---|---|
25 | |
10 | |
8 | |
7 | |
6 |
User | Count |
---|---|
32 | |
12 | |
10 | |
10 | |
9 |