With SQL Server 2022+ Do I Have To Migrate Code Away From SqlConnection Class Objects?

Question

EDIT: I understand the migration from System.Data.SqlClient to Microsoft.Data.SqlClient for newer .NET projects. What I am failing to understand is how the *.Data.SqlClient namespace communicates with SQL Server. This question comes to mind considering that Microsoft has now deprecated one of its clients, the SQL Native Client (SNAC).

i.e. How does the *.Data.SqlClient namespace communicate with SQL Server 2022 databases? Do developers need to worry about their codebase with the announcement of the deprecation of SQL Native Client?

---

Coding in C# and using a Microsoft SQL Server back-end, we are currently migrating databases from SQL Server 2019 to the newer SQL Server 2022 environment. Our codebase explicitly uses SqlConnection objects from the System.Data.SqlClient or newer Microsoft.Data.SqlClient namespace.

According to Microsoft's website, the SQL Server Native Client (SNAC) is now deprecated in SQL Server 2022. Will our codebase need to be migrated away from using System.Data.SqlClient.SqlConnection objects (or Microsoft.Data.SqlClient.SqlConnection) in order to continue to function with newer SQL Server 2022(+) instances?

Example connection string:

<add name="myConnection" 
     connectionString="Server=DEV-SQLSERVER2019-01.mycompany.local,1433;TrustServerCertificate=True;Database=Tokens;User ID=TokensApp;Password=ABC123"  
     providerName="Microsoft.Data.SqlClient"/>

Example code:

//using System.Data.SqlClient;
using Microsoft.Data.SqlClient;

private static string CreateToken(string code, string email)
{
    string token;

    try 
    {
        using (SqlConnection sqlConn = new SqlConnection(ConfigurationManager.ConnectionStrings["myConnection"].ConnectionString)) 
        {
            sqlConn.Open();

            using (SqlCommand sqlCmd = new SqlCommand()) 
            {
                sqlCmd.Connection = sqlConn;
                sqlCmd.CommandType = CommandType.StoredProcedure;
                sqlCmd.CommandText = "spCreateToken";
                sqlCmd.Parameters.Add("@Token", SqlDbType.UniqueIdentifier).Value = NEW_GLOBAL_TOKEN();
                sqlCmd.Parameters.Add("@Code", SqlDbType.NVarChar, 6).Value = code.ToUpper();
                sqlCmd.Parameters.Add("@Email", SqlDbType.NVarChar, 80).Value = email.ToLower();

                token = sqlCmd.ExecuteScalar().ToString();
            }
        }
    }
    catch (SqlException exSQL) when (exSQL.Message.Contains("Violation of UNIQUE KEY constraint")) 
    {
        throw new Exception(String.Format("This email address '{0}' has already been sent an invitiation.", email));
    }
    catch (Exception ex) when (ex.Message.Equals("Object reference not set to an instance of an object.")) 
    {
        throw new InvalidOperationException(String.Format("The email address provided '{0}' has already signed-up.", email));
    }

    return token;
}

If this codebase does need to be changed—How should I go about interfacing Microsoft SQL Server 2022+ databases within my C# codebase with regards to:

• Connection string format
• Database connection class type
• Database command class type
• Individual database object type(s)
• Individual database exception class type(s)
• Database transaction class type(s)
• SQL Server database user-defined values / table-valued parameter type(s)

I've read the deprecation changes coming to the new SQL Server 2022, but I am confused as to If or How this will actually affect our codebase that uses C# and explicitly calls the SqlConnection class to connect to our Microsoft SQL Server databases. It looks as though the migration path, if necessary, will be cumbersome to ensure proper functionality using a new SQL client object type.

Answer 1

SQL Server Native Client has absolutely nothing to do with SqlClient in C#. It's an ODBC driver which is used by C/C++ and other tools which utilize ODBC.

It's just chalk and cheese, apples and oranges, a non-sequitur. It's completely, totally, utterly and absolutely irrelevant to the conversation, it has no bearing on it, it's in another world. In C#, forget you ever heard of Native Client, it's not for you.

All you need to worry about is Microsoft.Data.SqlClient or the older but still supported System.Data.SqlClient.