Forum Discussion
Advocate VData Refresh Errors after Enterprise Gateway upgrade
Advocate VI was given a bandaid. There's a config file for the gateway...same one where you update the Trusted Servers. One of the flags in the file is "NextResultSkipped." They had me flip that to True. It killed the refresh errors, allowing the reports to refresh. I've not been able to get them to explain exactly what that does, but CoPilot says it basically tells the refresh not to get data it doesn't need to refresh the report--but I have no idea how the engine determines that. The tech support folks really really wanted me to close the ticket before the end of the year with the promise that they'd reach out to me after the 3rd week of the new year--but I have yet to hear from them and have been too busy to reach out. The whole process this time has been less than satisfactory. I actually sent a request to have the ticket escalated and while that may have happened, they've forced me to continue working with someone I have a very hard time communicating with.
Ping me if you want to know more about the band aid and I can tell you exactly what to do.
Hi motoray , are you still using the bandaid till now? We're past 6 months of frustration as well.
After working extensively with Microsoft, was determined SQL connection was hanging causing the timeout error. To resolve:
Go to:C:\Program Files\On-premises data gateway\Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config
Change <value> setting
<setting name="NextResultSkipped" serializeAs="String">
<value>True</value>
</setting>
Since making this change we haven't had any additional errors for this. This solution is not documented anywhere.Long story short after our own support ticket: There is no other option than to change the setting on the gateway as described. I can confirm refreshes no longer fail.
They said that if changing this setting has positive results, it means the underlying cause is a network delay in critical operations. This setting skips the processing of sensitivity label metadata, which is a time-critical operation causing a failure for the wider refresh. Most queries don't have an associated label. An update in the future will include changes to be more resilient with such network latency issues and remove this setting.
Our understanding (accurate or not) is that the (SQL) connection hangs for whatever reason and switching that setting forces it to drop ... or some such thing. We focused on one report that was erroring and it happened to be using an SQL connection otherwise it was chasing ghosts.
- motoray
That's the exact same one they had me implement. After each gateway upgrade, they'd have me flip the switch back to False and we'd watch for failures. When the failures came back (as they have since the Jan. 2025 update), we'd go back and flip the switch back.
JohnJ2, did they ever explain what that switch actually does and how? I never got a good answer from Microsoft. CoPilot said something about it telling the Gateway to only load stuff it needs to refresh, but that left me with more questions than answers. When I asked the question of Microsoft, the best answer they could provide was something like, "when you change that value to true, your errors go away." - motoray
Thanks for that explanation JohnJ2 -- it's more than I got from anyone else. All of our failures have been with on-prem SQL connections through the gateway.
Just did another call with a different Microsoft tech and passed off more dataset and request IDs and log files for them to look at. 
Any update for you guys? motoray
- motoray
I've been out of the office a while, so a colleague has been keeping this going with Microsoft. We were bascially told that they were going to change the configuration to default to True in the config file going forward, but there were no other details beyond that. This has been a most unsatisfatory support experience. Everything worked fine up until about July of last year and then it's been failures since.
