"Unable to get errors for your queries" message--can't find the error by inspecting said query

[MONTGM]

Is there some way to figure out what this error is? I've scrolled through the whole query that supposedly contains the error and found none.

[v-qiuyu-msft]

Hi @MONTGM, 

Form the screenshot, the error occurs with the second query Current. Please open Query Editor, then find the query Current, go to Applied Steps pane, click on each step, find which step has the error. 

Best Regards,
Qiuyun Yu 

[MONTGM]

Clicking through the applied steps is useless when the query is over 1000 rows long, and the error doesn't appear in those preview rows. The error is inside a table that is in a cell, so it doesn't appear in any of the applied steps.

I ended up finding the error just by spending an entire workday scrolling through the last step of the Current table query after adding a couple filters. Waiting 10 minutes for each 50 rows to load--excruciating.

If Power BI can tell me there's an error inside a query, surely it's possible to providethe query editor row index for that row...right?

[v-qiuyu-msft]

Hi @MONTGM,

>> If Power BI can tell me there's an error inside a query, surely it's possible to providethe query editor row index for that row...right?

You can submit a idea here: https://ideas.powerbi.com/forums/265200-power-bi-ideas

Best Regards,
Qiuyun Yu 

[NoMoreBugs]

Hi,

I got the same error this morning in our company's biggest pbix file, and PowerBI Desktop just never show out the errors to me. Then I opened a brand new pbix file with nothing in it, and just load that table reporting the errors. After loading the data to the pbix file, and click the 'View error' just like normal, now PowerBI searched out that 3 errors out of 20,000 rows of data. But the error query failed after running for 30 min. Then I created a blank query, and copied the M code of the error query to a blank query's Advanced Editor from first step source, to the step #"Kept Errors", and changed the output step after 'in' to #"Kept Errors". It ran for about 30min, and I got the errors. They are '#N/A' values under a decimal number column.

If this doesn't work. Another way I could think out when having this problem is that instead of verifying each row mannually, try to find which columns have the error first. From my perspective, a lot of times, the errors of a query is because the value violates the data type defined. Therefore, text columns will be pretty safe. We can delete all the text column in the test query, and looking for error for each column.

Best regards,

NoMoreBugs