OLE DB or ODBC error with Databricks: Temporary Result File URL Expired

[data_msfabric]

Hi Power BI Community,

We're encountering the following error after migrating our data source from SQL Server to Azure Databricks and re-pointing our reports in Power BI:

OLE DB or ODBC error: [DataSource.Error] ERROR [HY000] [Microsoft][Hardy]
(35) Error from server: error code: 'O' error message: '[Microsoft][Hardy] (134)
File 053da7d2-8aa6-464b-9070-9c24ca3d45fb: A retriable error occurred while attempting to download a result file from the cloud store but the retry limit had been exceeded. Error Detail: File 096da7d2-8aa6-464b-9070-9c24ca3d45fb: The result file URL had expired on 1745230218208 (Unix timestamp)'

Scenario:

• Power BI report was working fine with SQL Server.

• After switching to Databricks and pointing queries through Power Query, the error occurs only when loading larger datasets (e.g., 100,000 rows).

• If we use TopN(10) or limit the dataset, the report loads successfully.

• We are using ODBC / Spark connector, and the data is accessed through DirectQuery / Import mode depending on test cases.

Suspected Cause:

From our analysis, it seems that Power BI is trying to download the result file via a temporary cloud storage URL provided by Databricks. For large datasets, the download takes longer, and the signed URL expires before the file can be retrieved, causing this error.

What We've Tried:

• Testing with small datasets (works fine).

• Checked cluster availability and performance.

• No custom timeout settings found so far on our Databricks workspace.

Request:

• Has anyone experienced this result file expiration issue with Databricks in Power BI?

• Is there a recommended approach to increase the result file TTL or manage large datasets more reliably in this scenario?

• Would using Azure Databricks connector (instead of ODBC) improve stability?

• Any best practices to avoid such timeouts or optimize large data loads?

Thanks in advance for your support and suggestions!

Best regards,

AR

[v-saisrao-msft]

Hi @data_msfabric,
I hope this information is helpful. Please let me know if you have any further questions or if you'd like to discuss this further. If this answers your question, please Accept it as a solution and give it a 'Kudos' so others can find it easily.
Thank you.

[v-saisrao-msft]

Hi @data_msfabric 

Thank you for reaching out to the Microsoft Fabric Forum Community. 

Hi @Akash_Varuna, thank you for your response and for pointing out key directions. Switching to the Azure Databricks connector can indeed improve stability, as it's designed specifically for this integration and handles query execution and result retrieval more reliably than generic ODBC or Spark connectors. Breaking down large queries and considering caching are also helpful suggestions, especially when dealing with performance bottlenecks.  

However, I believe the core issue here is related to the expiration of the temporary result file URL provided by Databricks for large datasets. It might also be helpful to use Import mode over Direct Query when feasible, implement incremental refresh for large datasets, or consult with the Databricks admin team regarding the result file TTL configuration. 

If this post helps, then please give us ‘Kudos’ and consider Accept it as a solution to help the other members find it more quickly. 

Thank you. 

[Akash_Varuna · Accepted solution]

Hi @data_msfabric  Switching to the Azure Databricks connector might improve stability, as it’s optimized for this use case. You could also break queries into smaller chunks or enable caching to improve performance.You can consult your Databricks admin to see if the TTL for result files can be extended to avoid timeouts.