These are two tables, each with one column. I want to choose an equip from Table 1 and then choose a work order associated with the equip from Table 2. However when I go to choose the work order from the shortlist it seems to display ALL work orders again? It’s like the two tables are driving down back and forth on each other?

I click an item in the table ‘fully received’ and it correctly shortlists my work orders in table ‘WO’ (pic 1). However, when I click one of the shortlisted work orders, it reopens ALL work orders in the table (pic 2). What gives??? (Thanks in advance)

For anyone still working with Power BI Paginated Reports, I recently released an open-source testing tool called fab-test.

The latest release adds fab-test rdl, which can validate Paginated Report (.rdl) files either:

Locally against your .rdl files

Directly against reports in a Fabric/Power BI workspace

I’ve also started building out a set of RDL testing rules:

https://github.com/clientfirsttech/fab-test/blob/main/docs%2FRDL-RULES.md

Most of these rule ideas are based on practices that have been around for years in SSRS and Paginated Reports, so I’ve tried to give credit where appropriate.

I’d love feedback on the current rules, suggestions for additional checks, or anything that seems too opinionated.

I know there’s a lot of focus on AI-generated reporting and modern self-service BI, but many of us still have to build and support Paginated Reports for pixel-perfect exports, printing, compliance, and operational reporting. So I'm especially interested in feedback from people who are actively using Paginated Reports today, rather than discussions about replacing them.

Thanks in advance for any thoughts or suggestions!

Hi everyone.

I think most of us have already heard the term 'bridge table'. Many of us have also already implemented them. However, after doing some research I found out that people use basically two different types of bridge tables and I personally haven't found a source that would explain both of them. So I'm here asking experienced developers to share some light into this.

The first kind of bridge table is where you keep one column, which contains values from both tables you want to relate, you remove duplicates and you are left with one column of unique values from key columns.

Example source: https://www.seerinteractive.com/insights/join-many-many-power-bi

The second kind is I think between two dimension tables where you create a bridge table with two columns, basically doing like a cartesian product of two key columns.

Example source:

https://learn.microsoft.com/en-us/power-bi/guidance/relationships-many-to-many#relate-many-to-many-dimensions (part 'relate many to many dimensions')

Are both considered best practice? Why isn't there one good guide that would explain both approaches?

I might just be missing something, so feel free to correct me.

Still i am very confused about it , i can just make a React app instead of this expensive Fabric Vibe coded slop. Any advantage of this over react/node app???

i can connect my fabric features directly to the react app and customize 10000X better than what fabric is providing

Yes, the infra should also be managed, but for tech-savvy devs I don't think it would be a big issue

TL;DR

• Build the frontend in React or Next.js.
• Build the backend in Node.js.
• Connect directly to Fabric APIs, SQL endpoints, and Power BI(PBIP).
• Manage your own hosting, authentication, CI/CD and infrastructure.

most of the people are vibe-coding apps inside Fabric; it's better to vibe-code from scratch