Utilisation bizarre de requête d'insertion, suppression

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:

---

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:

---

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é.

Si tu utilises ca:

Code:

---

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

---

avec

Code:

---

Dim Oda As New SqlClient.SqlDataAdapter

---

et

Code:

---

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.

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.

Citation:

---

Envoyé par mactwist69

...
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,

Citation:

---

Envoyé par Graffito

...
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.

Citation:

---

Envoyé par Graffito

...
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)

Citation:

---

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!