SQLException.Number property differs on Linux OS and Windows. #1773
Labels
💡 Enhancement
Issues that are feature requests for the drivers we maintain.
🔨 Breaking Change
Issues/PRs that are related with breaking API changes in the driver.
Comments
ghost
added
the
|
Tagging subscribers to this area: @cheenamalhotra, @David-Engel Issue DetailsHello. Could you please clarify the behavior of the following code example: public static void Main(string[] args)
{
try
{
var connectionString =
"Server=non-existent-server;Database=nonexistentDb;User ID=sa;Password=invalidPassword;max pool size=1000";
var sqlConnection = new SqlConnection(connectionString);
sqlConnection.Open();
Console.WriteLine("Opened!");
sqlConnection.Close();
}
catch (SqlException sqlException)
{
Console.WriteLine(sqlException.ToString());
Console.WriteLine($"SQLException.Number: {sqlException.Number}");
}
}Running it on Windows 10 Pro 19044.2006 results in: Running the same code on Ubuntu 20.04 results in: So is it expected behavior that SQLException.Number equals 0 on Linux and 53 on Windows (Seems like 53 is the inner Win32Exception error number, meanwhile the same exception on Linux has inner ExtendedSocketException and SQLException.Number equals 0). If so, are there any workarounds to determine the cause of connection error regardless of platform? Thanks,
|
|
Hello, Sorry for bothering, do you have any updates? Thanks, |
|
@g-lashuk please note the providers are different in both stacktraces, as TCP is default on Unix, and Named pipes is default on Windows. You may prefix server name with “np:” or “tcp:” to specifically choose a protocol and compare behavior. |
|
Thanks, @cheenamalhotra I've tried your suggestion but it didn't seem to help: using "tcp:" prefix on Windows ended up with the following stack trace (SQL.Number is 11001, on Linux it's 0 like in the attachment above): I also tried to use "np:" prefix on Linux but I had the following exception (At the same time on Windows SQLException.Number is 53): I will be glad to receive any feedback, thanks. |
|
The last stsck trace does not use the current driver, but uses System.Data.SqlClient, which is in extended support state. |
|
@ErikEJ The behavior is the same regardless of using System.Data.SqlClient or Microsoft.Data.SqlClient |
|
The underlying networking stacks can return different information on different operating system. This appears to be the expected behavior. |
lcheunglci
added
🎨 By Design
|
Opening this issue as there is potential to enhance the exception messages. |
DavoudEshtehari
added
💡 Enhancement
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello.
Could you please clarify the behavior of the following code example:
Running it on Windows 10 Pro 19044.2006 results in:
Running the same code on Ubuntu 20.04 results in:
So is it expected behavior that SQLException.Number equals 0 on Linux and 53 on Windows (Seems like 53 is the inner Win32Exception error number, meanwhile the same exception on Linux has inner ExtendedSocketException and SQLException.Number equals 0). If so, are there any workarounds to determine the cause of connection error regardless of platform?
PS: The behavior is the same using System.Data.SqlClient or Microsoft.Data.SqlClient
Thanks,
Gleb
The text was updated successfully, but these errors were encountered: