How to use DirectQuery table with complex visuals

That error usually means Power BI has generated a SQL query that is too complex for the source to execute efficiently. I've run into this with DirectQuery models that use a combination of field parameters, complex measures, many relationships, and visuals that require multiple levels of aggregation.

A few things I'd try:

• Use Performance Analyzer to identify which visual is generating the problematic query.
• Simplify field parameter logic where possible. Field parameters can sometimes produce much larger SQL queries than expected in DirectQuery mode.
• Move complex calculations from DAX into the source database (SQL view or stored procedure) so Power BI has less work to push down.
• Consider a Composite Model instead of making the entire table DirectQuery. Keep large fact tables in DirectQuery and import smaller dimensions/aggregations.
• Create aggregation tables and let Power BI hit the imported aggregate table first, falling back to DirectQuery only when needed.
• Review any measures that use iterators such as SUMX, FILTER, ADDCOLUMNS, or nested CALCULATE statements, as these can generate very complex SQL in DirectQuery.
• Check whether bi-directional relationships can be reduced or replaced with a simpler model.

One thing that stands out is that the report worked in Import mode but ran out of memory. In that situation, I'd usually look at aggregations, incremental refresh, model optimization, or a Composite Model before converting the entire dataset to DirectQuery. DirectQuery often solves the memory issue but introduces query complexity issues like the one you're seeing.

Also, if you're using SQL Server, try capturing the generated SQL with SQL Profiler or Extended Events. Even when Power BI doesn't show the full query, the database side can often reveal which part of the query is causing the nesting limit or timeout.