It will (1) be able to catch more problems, and (2) will provide much more information when something goes wrong (including the exact line number when running in Visual Studio); you may not understand all of its output right away, but that typically is the info one needs to easily pinpoint what went wrong.
Hello sir and thank you for the info, I think I saw it when I was doing my research. And it was written only to see the problems with connection to the database. So I would like to know if we could use it only at the connection of the database or not?
Throws the sql_cmd variable away and sets it to a new OleDbCommand instance;
Attempts to execute the sql_cmdwithout adding any parameters to it;
This is yet another reason not to store the OleDbConnection and OleDbCommand objects in class-level fields. The first bit of your code is manipulating a command from a previous method. If the sql_cmd field hasn't been initialized, you may even get a NullReferenceException.
Change your code to create and use a new OleDbCommand instance, wrapped in a using block:
string connetionString = null;
//connection à la base de donnée avec mot de passe
connetionString = @"Provider=Microsoft.Jet.OLEDB.4.0;Data source=" + Application.StartupPath + @"\DB_CaisseEnregistreuse.mdb;Persist Security Info=True;Jet OLEDB:Database Password=B@sta08091987";
sql_con = new OleDbConnection(connetionString);
catch (Exception ex)
MessageBox.Show("Erreur de connexion à la base donnée" + ex.Message);