Forum Discussion
Dataflow Failed - Internal Error
Hi All,
Seems that during a dataflow refresh a file was created didn't get cleared out - and the presence of this file blocked subsequent refreshes.
Our Licenses entity has a number of tables, but the refresh always failed when it got to the LicenseRenewals table. In Azure Storage explorer I could see there was also a LicenseRenewals.CSV file in the Licenses folder, but no such file exists for the other folders.
On a whim I renamed this file and the extract worked again. Basically this file should not be there. These 'root' CSV files get created during data extract, then moved to their respective snapshot folder, then the 'root' CSV is removed and the next folder updated.
MS Support indicated that, for some as yet unknown reason, it looks like in our case the 'root' CSV file was not removed, and therefore on the next refresh it failed because it's trying to create a LicenseRenewals.CSV file but a duplicate is already present so it bombs out with the 'internal error' message in the logs.
So - the solution in our case was to remove/rename the offending 'root' CSV file.
We're using our own ADLSGen2 storage, so current working theory is that some interuption happened to that which stopped the file being removed normally and left this file as a hangover. But thats speculative.
Hopefully this answer helps others!
We're not using premium - and I see no option for the feature you referenced in the admin portal.
And another four dataflows started failing since yesterday - so now i'm up to eleven failures.
I'll contact support.
Hi Anonymous ,
Did you solve the issue? Can you please share us some messages? More people who encounter the same issue will benefit here.
Best Regards,
Xue Ding
If this post helps, then please consider Accept it as the solution to help the other members find it more quickly. Kudos are nice too.
No update as yet - still with support, has been escalated.
And still with support. The issue got referred to the Azure team to check the ADLS Gen2 was set up correctly with the proper service access - they're happy the access is there, so now we're back to the PBI team.
