Discussion :

[rv26t]

Bonjour,
Je reprend un programme et la façon d'utiliser les requêtes d'insertion, mise à jour et suppression me surprennent.

la variable "sQuery" contient la requête. (INSERT INTO table ...) ou (DELETE FROM ...) etc.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
    Dim oConnection As New System.Data.SqlClient.SqlConnection(ConnStr)
    oConnection.Open()
    Dim cmd As New SqlClient.SqlCommand(sQuery, oConnection)
    cmd.CommandType = CommandType.Text
    Dim Oda As New SqlClient.SqlDataAdapter
    Oda.SelectCommand = cmd
    Dim MyDs As New DataSet
    Try
      Oda.Fill(MyDs)
    Catch ex As Exception
...

Cela fonctionne mais ...


J'utilise plutôt cette façon de faire avec une commande "ExecuteNonQuery"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    Dim oConnection As New SqlConnection(ConnStr)
    Try
      oConnection.Open()
      Dim oCommand As New SqlCommand(sQuery, oConnection)
      oCommand.CommandType = CommandType.Text
      oCommand.ExecuteNonQuery()
    Catch Ex As Exception
...

Qu'en pensez-vous?

A+, Hervé.

[mactwist69]

Si tu utilises ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 Dim cmd As New SqlClient.SqlCommand(sQuery, oConnection)

avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Dim Oda As New SqlClient.SqlDataAdapter

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 Oda.Fill(MyDs)

Qu'est ce que ça va faire: Ça va exécuter ta requête et si des lignes sont retourner (comme avec un SELECT), et bien elles seront stockés dans ton dataset.

Si ta requête ne retourne rien (Delete), et bien il va simplement rien mettre dans ton dataset.

Mais je pense qu'il faut privilégié le Execute Query pour ce genre de requete.

[Graffito]

Le programme utilise les DataAdapter qui permettent :

• de charger une DataTable via la commande Fill du DataAdapter (qui utilise la SelectCommand définie pour l'adapter),
• de faire des modifications locales dans la datatable,
• de valider ces modifications par la methode Update du DataAdapter (qui utilise les insertCommand, deletecommand et updatecommand définies pour l'adapter, a la "mano" ou via le CommandBuilder).

C'est cette même technique que nous utilisons généralement.

[rv26t]

...
Qu'est ce que ça va faire: Ça va exécuter ta requête et si des lignes sont retourner (comme avec un SELECT), et bien elles seront stockés dans ton dataset.
...

Sachant que le dataset représente un cache en mémoire de données,

...
de faire des modifications locales dans la datatable,
...

que le datatable représente une table de données en mémoire,

tout reste donc en mémoire.

...
de valider ces modifications par la methode Update du DataAdapter (qui utilise les insertCommand, deletecommand et updatecommand définies pour l'adapter, a la "mano" ou via le CommandBuilder).
...

Il n'y a pas cette partie là. (et il ne me semble pas l'avoir vu ailleur dans le programme, il faut que je vérifie lundi)

Quand la modif est faite elle apparait bien dans les liaisons de données d'affichage, mais rien en immédiat dans la BDD.
Les données sont enregistrées dans la BDD un peu plus tard. Il faut que je vérifie à quel moment.

Cela va pour une utilisation mono-utilisateur, mais pas multi-utilisateur.
Je vais reprendre cela lundi pour corriger.


Merci pour vos explications.


En terme de performance quelle serait la meilleure approche ? (par SqlDataAdapter ou ExecuteNonQuery)

[Graffito]

Cela va pour une utilisation mono-utilisateur, mais pas multi-utilisateur.

Oui, et en pratique, on fait une instruction DataAdapter.Update à chaque insertion, suppression ou modification, pour pouvoir avertir l'utilsateur immédiatement.

Si on fait l'update à la fin, ca peut passer pour 90% des modifs et coincer sur 10%.
Dans ce cas, sauf à faire une transaction globale sur l'ensemble des modifs, on ne sait plus vraiment où on en est!