SqlConnection.Open() Establishing a connection EVERY query?

In my Winforms app which uses a remote database, I have the function below. (I also have two other functions which work similarly: One for scalar queries which returns zero upon failure, the other for updates and inserts which returns false upon failure.)

Currently, ALL data manipulation is pumped through these three functions.

It works fine, but overall please advise if I’d be better off establishing the connection upon launching my app, then closing it as the app is killed? Or at another time? (Again, it’s a windows forms app, so it has the potential to be sitting stagnant while a user takes a long lunch break.)

So far, I’m not seeing any ill effects as everything seems to happen “in the blink of an eye”… but am I getting data slower, or are there any other potential hazards, such as memory leaks? Please notice I am closing the connection no matter how the function terminates.

Public Function GetData(ByVal Query As String) As DataTable
    Dim Con As New SqlConnection(GlobalConnectionString)
    Dim da As New SqlDataAdapter
    Dim dt As New DataTable
    Try
        Con.Open()
        da = New SqlDataAdapter(Query, Con)
        Con.Close()
        da.Fill(dt)
    Catch ex As Exception
        Debug.Print(Query)
        MsgBox("UNABLE TO RETRIEVE DATA" & vbCrLf & vbCrLf & ex.Message, MsgBoxStyle.Critical, "Unable to retrieve data.")

    End Try
    da.Dispose()
    Con.Close()
    Return dt
End Function

Answer

There are exceptions to this, but best practices in .Net do indeed call for creating a brand new connection object for most queries. Really.

To understand why is, first understand actually connecting to a database involves lots of work in terms of protocol negotiations, authentication, and more. It’s not cheap. To help with this, ADO.Net provides a built-in connection pooling feature. Most platforms take advantage of this to help keep connections efficient. The actual SqlConnection, MySqlConnection, or similar object used in your code is comparatively light weight. When you try to re-use that object, you’re optimizing for the small thing (the wrapper) at the expense of the much larger thing (the actual underlying connection resources).

Aside from the benefits created from connection pooling, using a new connection object makes it easier for your app to scale to multiple threads. Imagine writing an app which tries to rely on a single global connection object. Later you build a process which wants to spawn separate threads to work on a long-running task in the background, only to find your connection is blocked, or is itself blocking other normal access to the database. Worse, imagine trying to do this for a web app, and getting it wrong such that the single connection is shared for your entire Application Domain (all users to the site). This is a real thing I’ve seen happen.

So this is something that your existing code does right.
However, there are two serious problems with the existing method.

The first is that the author seems not to understand when to open and when to close a connection. Using the .Fill() method complicates this, because this method will open and close your connection all on its own.¹ When using this method, there is no good reason to see a single call to .Open(), .Close(), or .Dispose() anywhere in that method. When not using the .Fill() method, connections should always be closed as part of a Finally block: and the easiest way to do that is with Using blocks.

The second is SQL Injection. The method as written allows no way to include parameter data in the query. It only allows a completed SQL command string. This practically forces you to write code that will be horribly vulnerable to SQL Injection attacks. If you don’t already know what SQL Injection attacks are, stop whatever else you’re doing and go spend some time Googling that phrase.

Let me suggest an alternative method for you to address these problems:

Public Function GetData(ByVal Query As String, ParamArray parameters() As SqlParameter) As DataTable
    Dim result As New DataTable()

    Using Con As New SqlConnection(GlobalConnectionString), _
          Cmd As New SqlCommand(Query, Con), 
          da As New SqlDataAdpapter(Cmd)

        If parameters IsNot Nothing Then Cmd.Parameters.AddRange(parameters)

        Try
            da.Fill(result)
        Catch ex As Exception
            Debug.Print(Query)
            'Better to allow higher-level method to handle presenting the error to the user
            'Just log it here and Rethrow so presentation tier can catch
            Throw 
        End Try
    End Using 'guarantees connection is not left hanging open
    Return result
End Function

---

¹See the first paragraph of the “Remarks” section.