topic Re: ODBC timeout expirations for sql endpoints on lakehouses (2026) in Data Warehouse

ODBC timeout expirations for sql endpoints on lakehouses (2026)

dbeavon3 — Thu, 09 Apr 2026 19:39:35 GMT

I got an error message from a sql endpoint on a lakehouse:

pyodbc.OperationalError: ('HYT00', '[HYT00] [Microsoft][ODBC Driver 18 for SQL Server]Login timeout expired (0) (SQLDriverConnect)')

Admittedly this is rare. I'm guessing it happens less than 1 in 50 connections or so. (my code has been running daily for three weeks before I saw this message).

However I do NOT look forward to yet another variety of intermittent failures so I want to understand what is happening. My code is already a workaround, and I'm guessing I will have to build in another layer of workarounds to accommodate this new sort of error.

Ideally the message would be improved. It teases us into thinking we can just extend the timeout (I reached the error after around 17 seconds, as I recall).

.When I started searching the internet for the RCA, I found this truly surprising explanation:
You must include Encrypt=yes;TrustServerCertificate=no; in your connection string. Without those, the ODBC driver silently fails during the Azure AD auth handshake, resulting in a timeout.

There are references to this error on reddit as well, without any authoritative responses. The explanation above rings true for Fabric, given how surprising and strange it is. Can someone share any documentation about this silent suppression of auth failures? And why these random changes to the connection string have any effect? I will probably open a support ticket with CSS-pro at Mindtree. Is there a prior SR# or ICM# that can be used as a reference? The MT engineers will probably have a hard time believing such an explanation without some sort of corroboration.

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

dbeavon3 — Thu, 09 Apr 2026 19:44:16 GMT

Hi v-lgarikapat Here is the question you asked me to repost, since your prior response was a year old.

I noticed you have a lot of expertise with DW and LH. Can you please share what you had learned about this error on SQL endpoints? I want to be able to dig into it to find a workaround when it happens, or avoid the problem in the first place. I will likely open an SR, and I'm hoping not to start from scratch - if you have already invested in an investigation with tech support. Do you have any docs, or SR#'s or ICM#'s that you can share?

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

v-karpurapud — Fri, 10 Apr 2026 10:10:53 GMT

Hi dbeavon3

Thanks for raising this your observation is correct. With ODBC Driver 18 for SQL Server, connection encryption is mandatory by default. If the connection string does not explicitly include

Encrypt=yes;TrustServerCertificate=no;

the TLS handshake during Azure AD authentication can fail silently. Instead of surfacing a certificate or SSL error, the driver reports a generic login timeout (HYT00).

Connection encryption troubleshooting - ODBC Driver for SQL Server | Microsoft Learn
Release Notes for ODBC Driver for SQL Server on Windows - ODBC Driver for SQL Server | Microsoft Learn

I hope the information shared helps you. If you need further assistance, please let us know.

Best regards,
Community Support Team

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

dbeavon3 — Fri, 10 Apr 2026 14:03:06 GMT

Hi v-karpurapud

I see that you shared some changes to the odbc client that are considered "breaking changes" and you also shared some troubleshooting steps for connectivity problems.

However I do NOT see anything in your post that mentions connection timeouts or suppressed error messages. Those are the things that I'm asking about in particular; together with the surprising workaround (which seems like something someone discovered randomly by trial-and-error and is probably not authoritative).

My hope is to move this discussion to an SR ticket, and then share the outcome back in the community once I have authoritative docs to reference. But I don't want to spend a month on a CSS-pro engagement since v-lgarikapat seemed to have already worked on this problem for a long time. See his proposal for a solution here:
https://community.fabric.microsoft.com/t5/Data-Warehouse/pyodbc-login-timeout-expired-when-connecting-to-Lakehouse-SQL/m-p/4716328

To ask another way, how can customers create a repro that is able to determine when TLS handshake failures are the root cause of a "Login timeout"? Is there a way to isolate those specific handshake problems so we can monitor them and alert Microsoft about them when they increase in frequency?

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

v-lgarikapat — Mon, 13 Apr 2026 10:53:25 GMT

Hi dbeavon3 ,

Thank you for your follow‑up questions. We have already provided solutions for the threads mentioned Solved: Re: pyodbc login timeout expired when connecting t... - Microsoft Fabric Community, referencing earlier issues raised in the community that were resolved and accepted by Ops. For example: Solved: Failed to access/connect to Lakehouse SQL Endpoint... - Microsoft Fabric Community

Thank you for your detailed explanation. It looks like you've already followed the recommended steps, but the issue still persists.

To help resolve this further, I recommend raising a support ticket so our support team can assist you directly.
Please refer to the following link for instructions on how to create a support ticket:

How to create a Fabric and Power BI Support ticket - Power BI | Microsoft Learn

We appreciate your engagement and thank you for being an active part of the community.

Best regards,
Lakshmi

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

dbeavon3 — Mon, 13 Apr 2026 12:43:36 GMT

Hi v-lgarikapat
Thanks for your reply,
Is there any supporting references that you can provide, which show that this is the fix for login timeouts?

You must include Encrypt=yes;TrustServerCertificate=no; in your connection string ...

I am not finding anything to corroborate that. It seems very arbitrary. If you have any basis for this information then please share it. I will include those details into my discussions when I open an SR with Mindtree.

Given how specific your instructions were, it seems like you are very confident. I am not doubting that your information is accurate. Without additional references it will be hard for me to use these forums as an authoritative source for the issue.

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

v-lgarikapat — Mon, 13 Apr 2026 15:40:46 GMT

Hi dbeavon3 ,

The connection string we suggested:

Encrypt=yes;TrustServerCertificate=no;

is based on Microsoft’s recommended secure configuration for ODBC Driver 18.

Encrypt=yes → ensures the connection is encrypted using TLS
TrustServerCertificate=no → enforces validation of the server’s SSL certificate (i.e., the certificate must be trusted and match the server)

ODBC Driver 18 enables encryption by default
When TrustServerCertificate=no, the client validates the certificate for security
When TrustServerCertificate=yes, certificate validation is bypassed (used only when a trusted certificate is not available)

Official references:

Configure Client Computer and Application for Encryption - SQL Server | Microsoft Learn

Connect Access to SQL Server - Microsoft Support

ODBC DSN and connection string keywords - ODBC Driver for SQL Server | Microsoft Learn

Hope This hepls!

Thanks,

Lakshmi.

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

dbeavon3 — Mon, 13 Apr 2026 17:30:20 GMT

Hi v-lgarikapat

When TrustServerCertificate=no; there is MORE work being done. So how does this avoid a login timeout issue? It might make more sense if you said to set TrustServerCertificate=yes.
... since that totally bypasses the certificate validation.

Is that what you meant to say?

Do you think it is commonly known that this fixes login timeout issues? Eg. would Microsoft/Mindtree agree with this approach? Or did you find it on your own via independent testing?

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

v-lgarikapat — Wed, 22 Apr 2026 09:37:00 GMT

Hi dbeavon3 ,
Thanks so much for your follow‑up questions -We appreciate your engagement.

We have provided this solution by referencing previously resolved threads where the approach worked as expected for other users.

If you would like more detailed assistance, we kindly suggest raising a support ticket so that the Support Team can help you further.

Solved: Re: pyodbc login timeout expired when connecting t... - Microsoft Fabric Community

pyodbc.OperationalError: ('HYT00', '[HYT00] [Microsoft][ODBC Driver 18 for SQL Server]Login timeout expired (0) (SQLDriverConnect) - Microsoft Q&A

Solved: Failed to access/connect to Lakehouse SQL Endpoint... - Microsoft Fabric Community

Please refer to the following link for instructions on how to create a support ticket:

How to create a Fabric and Power BI Support ticket - Power BI | Microsoft Learn

We appreciate your engagement and thank you for being an active part of the community.

Best regards,
Lakshmi

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

dbeavon3 — Wed, 22 Apr 2026 13:35:41 GMT

It is unlikely that this has worked for anyone. I'm still looking for authoritative references that say the fix for timeouts is to use Encrypt=yes;TrustServerCertificate=no . I don't think that is the case. If it does anything, in increases the chance of errors when verifying TLS certs and encrypting data.

The support ticket will not go well if this is my starting point. It is probably going to add even more time/effort to the support ticket if the starting point is to share lots of unconfirmed guesswork from community members. It would be better if there was documentation that clearly stated what connection string properties had some sort of an influence on connection timeouts. But none of the links to Microsoft docs seem to say anything about timeouts.

FYI, There is lots of noise in this community, and it doesn't help the AI/LLM search models (goggle) when we reinforce them with superstitious guesses about how to eliminate timeouts. Timeouts are a very common, but intermittent problem in a coud environment. Any fix that resolves these timeouts is HIGHLY desirable. But any unconfirmed and non-authoritative guesses about how to fix them are not desirable at all, since it just muddies the water.

Re: ODBC timeout expirations for sql endpoints on lakehouses (2026)

v-lgarikapat — Tue, 28 Apr 2026 11:57:55 GMT

Hi dbeavon3 ,

We appreciate your feedback and are doing our best to improve. For documentation-related concerns, please reach out directly to the Support team.

Thanks,

Lakshmi