2012-09-19 19 views
8

Tome el ejemplo siguiente ...SqlCommand (using/Eliminación tema)

 Using cn As New SqlConnection(ConnectionString) 
      Try 
       Dim cmd As SqlCommand = New SqlCommand 
       With cmd 
        .Connection = cn 
        .Connection.Open() 
        .CommandText = "dbo.GetCustomerByID" 
        .CommandType = CommandType.StoredProcedure 
        .Parameters.Add("@CustomerID", SqlDbType.Int, 4) 
        .Parameters("@CustomerID").Value = CustomerID 
       End With 

       da = New SqlDataAdapter(cmd) 
       da.Fill(ds, "Customer") 
      Catch ex As Exception 

      End Try 
     End Using 

De mi investigación actual se suena como si esto es básicamente bien, pero el SqlCommand no está siendo eliminado.

Pregunta -> ¿Cuál de los siguientes ejemplos es la mejor manera de lidiar con esto?

Ejemplo 2 - Eliminar manualmente

 Using cn As New SqlConnection(ConnectionString) 
      Try 
       Dim cmd As SqlCommand = New SqlCommand 
       With cmd 
        .Connection = cn 
        .Connection.Open() 
        .CommandText = "dbo.GetCustomerByID" 
        .CommandType = CommandType.StoredProcedure 
        .Parameters.Add("@CustomerID", SqlDbType.Int, 4) 
        .Parameters("@CustomerID").Value = CustomerID 
       End With 

       da = New SqlDataAdapter(cmd) 
       cmd.Dispose() 
       da.Fill(ds, "Customer") 
      Catch ex As Exception 

      End Try 
     End Using 

Ejemplo 3 - Automatic desechar con la declaración Usando

 Using cn As New SqlConnection(ConnectionString) 
      Try 
       Using cmd As New SqlCommand 
        With cmd 
         .Connection = cn 
         .Connection.Open() 
         .CommandText = "dbo.GetCustomerByID" 
         .CommandType = CommandType.StoredProcedure 
         .Parameters.Add("@CustomerID", SqlDbType.Int, 4) 
         .Parameters("@CustomerID").Value = CustomerID 
        End With 

        da = New SqlDataAdapter(cmd) 
        da.Fill(ds, "Customer") 
       End Using 
      Catch ex As Exception 

      End Try 
     End Using 

Ejemplo 4 - El mismo que en el ejemplo 3 pero el Try/Catch está dentro del Uso - ¿Esto hace la diferencia?

 Using cn As New SqlConnection(ConnectionString) 
      Using cmd As New SqlCommand 
       Try 
        With cmd 
         .Connection = cn 
         .Connection.Open() 
         .CommandText = "dbo.GetCustomerByID" 
         .CommandType = CommandType.StoredProcedure 
         .Parameters.Add("@CustomerID", SqlDbType.Int, 4) 
         .Parameters("@CustomerID").Value = CustomerID 
        End With 

        da = New SqlDataAdapter(cmd) 
        da.Fill(ds, "Customer") 
       Catch ex As Exception 

       End Try 
      End Using 
     End Using 

Ejemplo 5 - Lo mismo que en el ejemplo 4, pero CommandText y CN se especifican en la instrucción using - ¿Qué ventaja tiene esto?

 Using cn As New SqlConnection(ConnectionString) 
      Using cmd As New SqlCommand("GetCustomerByID", cn) 
       Try 
        With cmd 
         .Connection.Open() 
         .CommandType = CommandType.StoredProcedure 
         .Parameters.Add("@CustomerID", SqlDbType.Int, 4) 
         .Parameters("@CustomerID").Value = CustomerID 
        End With 

        da = New SqlDataAdapter(cmd) 
        da.Fill(ds, "Customer") 
       Catch ex As Exception 

       End Try 
      End Using 
     End Using 

Ejemplo 6 - Lo mismo que en el ejemplo 5 pero la conexión se abre en cn en lugar de cmd. ¿Es mejor abrir la conexión en cmd si solo se va a ejecutar un procedimiento almacenado?

 Using cn As New SqlConnection(ConnectionString) 
      cn.Open() 

      Using cmd As New SqlCommand("GetCustomerByID", cn) 
       Try 
        With cmd 
         .Connection = cn 
         .CommandType = CommandType.StoredProcedure 
         .Parameters.Add("@CustomerID", SqlDbType.Int, 4) 
         .Parameters("@CustomerID").Value = CustomerID 
        End With 

        da = New SqlDataAdapter(cmd) 
        da.Fill(ds, "Customer") 
       Catch ex As Exception 

       End Try 
      End Using 
     End Using 
+1

La sentencia using es más segura, pero se desaconseja un try/catch que ignora todas las excepciones en la mayoría de las situaciones. Entonces, cómo y dónde pones tu intento de captura depende de lo que estás tratando de lograr. ¿Cuál es tu pregunta? –

+0

me parece que esta pregunta es más adecuada para codereview.stackexchange.com –

+0

El try/catch vacío era solo un ejemplo, pero en este caso solo estaba ahí por seguridad. Externo al procedimiento en el que estaba esto iba a verificar que el conjunto de datos contenía alguna tabla. Si no fuera así, me ocuparía de manera apropiada. En cuanto a la pregunta, estaba en la cima, me preguntaba cuál es la mejor manera de lidiar con la eliminación de SqlCommand. Personalmente creo que el Ejemplo 5 es el correcto, pero quería saber los comentarios de los demás. –

Respuesta

7

El comando DataAdapter.Fill se abrirá y cerrará la conexión en sí, por lo que no necesita el cmd.Connection.Open(). (Ref.: La sección de observaciones en http://msdn.microsoft.com/en-us/library/377a8x4t.aspx)

Usando Using para el SqlConnection tiene el efecto de llamar .Close en él para usted.

La variable cmd se convierte en elegible para la recolección de basura una vez que está fuera del alcance (o antes si .NET determina que no se va a usar de nuevo).

En su ejemplo 2, no estoy seguro de que sea una buena idea deshacerse del cmd antes de que DataAdapter lo haya utilizado.

+0

Gracias. No sabía eso sobre los adaptadores de datos así que lo modificaré en consecuencia. Entonces, si el elemento se vuelve elegible para la recolección de basura, ¿está diciendo que la declaración de Uso no es realmente necesaria? –

+0

@cw_dev Sí. Una cosa que sí me mordió es la siguiente: 'Usando cmd ... cmd.Connection = ... cmd.Connection.Open() ... (ejecuta y lee) ... End Using' que no se cierra la conexión dentro del cmd. Sin embargo, no parece que vas a estar haciendo eso. El uso de 'Using' en una SqlConnection es un método conveniente para hacerlo .Close() la conexión por usted. –

Cuestiones relacionadas