Timeout on Auto refresh

[GrahamR99]

Hello

We have serveral Power BI reports on the Power BI Service that are shared, they auto refresh every day, however most days the timeout, with this error;

{"error":{"code":"DM_GWPipeline_Gateway_AdoNetProviderExecuteQueryTimeoutError","pbi.error":{"code":"DM_GWPipeline_Gateway_AdoNetProviderExecuteQueryTimeoutError","parameters":{},"details":[]}}} Table: Merge1.

I just keep manually re-running the refresh until it works.

I would like to solve this issue, can anyone tell me where to start?

Regards

GrahamR99

[RoopaR]

My issue resolved after admin restarted the gateway. He also downloaded and installed newest version out there. No problem with auto-refreshes  or scheduled refreshes so far. If the data pull is complex enough for request to time-out, have you considered incremental refresh? I did that with 2 of my reports and no issues with time-out now - but this is a specific situation where I know the reason behind the error. It was 56 million+ records and loading through a compelx SQL view. Please try that and update here to see if it resolves your problem?

[PijushRoy]

Hi @RoopaR @GrahamR99 @Anonymous 

Sometimes timeout issues occur, due to the server being busy.

When Power BI reads the table, at the same time same table is used to write data or other reports reading data from the same table.
Please look into the data model which table uses same time refresh, optimize your report, how much time it takes when the server is not in use, etc
If you face the same issue, please try to connect to Microsoft support

If solved your requirement, please mark this answer as SOLUTION.
If this comment helps you, Like 👍 this comment 

Thanks
Pijush

[PijushRoy]

Hi @RoopaR @GrahamR99 @alex_j 

After troubleshooting the below information, 
When Power BI reads the table, at the same time same table is used to write data or other reports reading data from the same table.
Please look into the data model which table uses same time refresh, optimize your report, how much time it takes when the server is not in use, etc

If you face the same issue, please try to connect to Microsoft support
If you have a Pro license you can open a Pro ticket at https://admin.powerplatform.microsoft.com/newsupportticket/powerbi
Otherwise you can raise an issue at https://community.fabric.microsoft.com/t5/Issues/idb-p/Issues .

If solved your requirement, please mark this answer as SOLUTION.
If this comment helps you, Like this comment 

Thanks
Pijush

[RoopaR]

Do either of you have a resolution to this? I have the same problem as well. I had the admin restart the gateway installed on-prem and then all refreshes went fine, but looks like its disconnected again from SQL server and my datasets aren't able to connect to SQL server via gateway while the gateway itself shows online in Power BI service

[PijushRoy]

Hi @GrahamR99 

Please try to put the report in a different refresh schedule time like the example below
1. One large dataset report, kept at 7.00 am
2. Two medium dataset reports at 7.30 am

Dont keep all reports in same time slot
Check your report performance issue and optimize your report
Search Google for "how to optimize power BI reports" and learn

[GrahamR99]

Hello @PijushRoy  

I have already tried different times, and that didn't work.  I have 7 reports auto refreshing 5 refreshes at 7:30am, one at 8am and one at 8:30am the two that run after 8 are the ones failing.

Is there no better solution than the time it runs, our organisation is planning to increase the amount of Power BI reports massively and if it can handle two reports now what's it going to be like in the future?

These reports that fail are not large datasets either, they are 500MB at most at a guess, still trying to work that out, but need Microsoft Fabric to work out and we don't have that yet.

Is there anything better you can suggest?

Regards

GrahamR99

[Anonymous]

I have the same here. Dataset has 500mb. Sometimes the refresh works, sometimes it doesn't. 

Sometimes takes 1 hour, and sometimes 2 hours. 

It's really hard to track where the bottleneck is.