J'utilise ce code:
public void InsertMember(Member member)
{
string INSERT = "INSERT INTO Members (Name, Surname, EntryDate) VALUES (@Name, @Surname, @EntryDate)";
using (sqlConnection = new SqlConnection(sqlConnectionString_WORK))
{
sqlConnection.Open();
using (SqlCommand sqlCommand = new SqlCommand(INSERT, sqlConnection))
{
sqlCommand.Parameters.Add("@Name", SqlDbType.VarChar).Value = member.Name;
sqlCommand.Parameters.Add("@Surname", SqlDbType.VarChar).Value = member.Surname;
sqlCommand.Parameters.Add("@EntryDate", SqlDbType.Date).Value = member.EntryDate;
sqlCommand.ExecuteNonQuery();
}
}
}
Est-ce une erreur si je n'ajoute pas sqlConnection.Close();
avant de le jeter? Je veux dire. Cela ne montre aucune erreur, aucun problème. Est-il préférable de le fermer en premier? Si oui pourquoi?
Pas besoin de Close or Dispose
, le bloc using
s'occupera de cela pour vous.
Comme indiqué dans MSDN :
L'exemple suivant crée un SqlConnection, l'ouvre, en affiche de ses propriétés. La connexion est automatiquement fermée à la fin du bloc d'utilisation.
private static void OpenSqlConnection(string connectionString)
{
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open();
Console.WriteLine("ServerVersion: {0}", connection.ServerVersion);
Console.WriteLine("State: {0}", connection.State);
}
}
Le using statement ensures that Dispose is called
même si une exception se produit lorsque vous appelez des méthodes sur l'objet. You can achieve the same result by putting the object inside a try block and then calling Dispose in a finally block
; En fait, c'est ainsi que l'instruction using est traduite par le compilateur. MSDN
Donc, finalement, votre ligne de code
using (sqlConnection = new SqlConnection(sqlConnectionString_WORK))
sera converti en un try finally block
normal par un compilateur appelant IDisposable object in the finally
L'instruction using est un bloc try et enfin, et dans votre cas, le bloc final aurait un appel connection.Dispose()
. Donc vous n’avez pas vraiment besoin d’une déclaration connection.Close()
indépendante ici.
L'avantage est que cela garantit la disposition même en cas d'exception puisque le bloc finally sera toujours exécuté.
try
{
sqlConnection.Open();
// ....
}
finally
{
if(sqlConnection != null)
sqlConnection.Dispose();
}
Selon la documentation MSDN pour la méthode Close
:
vous devez explicitement fermer la connexion en appelant Close ou Dispose. Close et Dispose sont fonctionnellement équivalents.
Par conséquent, appeler Dispose
(implicitement, même en utilisant using
) couvrira vos bases, pour ainsi dire.
Il convient également de noter que, même si cela n’est pas spécifique à votre cas, Close
sera toujours appelé lorsque la chose est encapsulée dans une instruction using
- ce qui pourrait non être le cas si elle est omise une exception se produit sans la manipulation try
/catch
/finally
appropriée.
Est-ce faux si je n'ajoute pas sqlConnection.Close (); avant de le jeter
Non, ce n'est pas tant que vous utilisez votre connexion dans Using
. Lorsque vous quitterez la portée using, Dispose
sera appelé pour une connexion SQL. qui fermera la connexion existante et libérera également toutes les ressources.
Non, ce n'est pas faux. SqlConnection ferme la connexion après avoir passé using block et appelle la méthode Dispose. SqlConnection.Dispose () égal à la méthode SqlConnection.Close ().
De MSDN: Si la SqlConnection sort de la portée, elle ne sera pas fermée. Par conséquent, vous devez explicitement fermer la connexion en appelant Close ou Dispose. Fermer et Éliminer sont fonctionnellement équivalents.
Vous utilisez une Using
qui Dispose()
l'objet pour vous.
Si vous prenez la connexion en dehors de l'instruction Using
, alors oui, vous devrez fermer la connexion lorsque vous avez terminé.
C'est une question très intéressante et pas si évidente que beaucoup peuvent penser. L'utilisation de l'instruction ne fonctionnera correctement pour la connexion que si tous les objets qui utilisent la connexion seront supprimés. Il y a quelque temps, nous avons eu un problème avec les connexions ouvertes sur notre serveur SQL. Tout semblait aller bien parce que les connexions utilisaient des instructions, mais l'un des développeurs a créé peu de méthodes avec SqlDataReader et ne l'a pas fermé correctement. A cause de cela, les connexions n'ont pas été libérées.
La raison en est la façon dont fonctionne garbage collecton. En résumé, il crée une carte des objets à disposer et les dispose réellement lorsqu'il n'y a pas de référence active à ces objets.