Vider une table en VBA

Bonjour,

Comment puis-je vider une table avec une instruction en VBA lorsque je quitte un formulaire?

Merci de votre aide

Bonjour

Code:

---

1 2 3 4

DoCmd.SetWarnings False 'empêche les messages d'alerte DoCmd.RunSQL "DELETE * FROM MaTable " DoCmd.SetWarnings True

---

Autre solution possible :

créer une requête de suppression (ex : rViderMaTable) et l'appeler à partir du code suivant :

Code:

---

1 2 3

dim db as dao.database:set db=currentdb db.querydefs("NomTaRequeteSuppression").execute db.close:set db=nothing

---

A+

OK !!

Merci à tous les 2 !

Je vais tester en priorité la solution en VBA ... lundi !

Bon WE !

En fait je n'ai pas pu résister à la tentation de tester vos proposition dès vendredi soir : Ça marche impec !!

... et en voici une troisieme qui ne generera aucun message de confirmation de la part d'Access :

Code:

---

Call CurrentDb.Execute("DELETE * FROM MaTable;")

---

Bon amusement ;)

Merci SSJconsult je ne connaissais pas celle la.

A+

Deux autres solutions :

Avec un recordset DAO

Code:

---

1 2 3 4 5 6 7 8 9 10

Sub Suppr1() Dim oRst As DAO.Recordset Dim oDb As DAO.Database Set oDb = CurrentDb Set oRst = oDb.TableDefs("Table1").OpenRecordset While Not oRst.EOF oRst.Delete oRst.MoveNext Wend End Sub

---

Avec un ordre SQL et ADO

Code:

---

1 2 3

Sub Suppr2() CurrentProject.Connection.Execute "DELETE FROM TABLE1" End Sub

---

Merci TOFALU, celle par la connexion est vraiment originale.

Intuitivement je pense que celles qui utilisent du SQL sont plus rapides que celle qui utilise du VBA mais quelqu'un a-t-il fait un comparatif sérieux. C'est de la pure curriosité car je n'ai pas de besoin dans ce domaine actuellement.

En tout cas en SQL cela nécessite moins de code.

A+

On m'a toujours dit que pour supprimer il valait mieux utiliser un truncate, surtout si ta table contient de grands quantité de données.

Code:

---

docmd.runSQL= "truncate table TABLE1"

---

RunSQL n'est pas une proprité mais une fonction. Le = générera donc une erreur de compilation

Quant à Truncate, il n'est pas utilisable dans Access

Citation:

---

Envoyé par marot_r

Merci TOFALU, celle par la connexion est vraiment originale.

Intuitivement je pense que celles qui utilisent du SQL sont plus rapides que celle qui utilise du VBA mais quelqu'un a-t-il fait un comparatif sérieux. C'est de la pure curriosité car je n'ai pas de besoin dans ce domaine actuellement.

En tout cas en SQL cela nécessite moins de code.

A+

---

Toutes celles utilisant des ordres SQL, soit générés depuis VBA soit via des querydef (requête enregistrées) vont avoir des performances semblables.
En revanche, les recordsets vont avoir des perfs lamentables plus le volume à traiter sera grand, qu'il s'agisse de recordset DAO ou ADO

L'avantage d'utiliser Execute (querydef ou Database) réside dans la gestion des erreurs (dbfailonerror) et dans le mode transactionnel qui permet de simuler la suppression afin de la confirmer ou de l'annuler sans passer par les traditionnels messages d'Access.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Sub Suppr2() On Error GoTo err Dim oDb As DAO.Database   Set oDb = CurrentDb   DBEngine.BeginTrans With oDb .Execute "DELETE FROM Table1", dbFailOnError If MsgBox("Supprimer " & .RecordsAffected & " lignes ?", vbYesNo) = vbYes Then DBEngine.CommitTrans Else DBEngine.Rollback End If End With   fin: Set oDb = Nothing Exit Sub     err: DBEngine.Rollback resume fin End Sub

---

Pour être complet :

L'utilisation de transaction avec AdoDb via l'objet Currentproject

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Sub Suppr32() Dim n As Integer   On Error GoTo err   With CurrentProject.Connection .BeginTrans .Execute "DELETE FROM TABLE1", n If MsgBox("Supprimer " & n & " lignes ?", vbYesNo) = vbYes Then .CommitTrans Else .RollbackTrans End If End With fin: Exit Sub   err: CurrentProject.Connection.RollbackTrans Resume fin End Sub

---

La gestion d'erreur est améliorable, impossible de rollback si c'est le begintrans qui lève l'erreur, mais le principe est là.
L'intéret est de comparer la manière dont on récupère le nombre de lignes affectées par la méthode Execute. Avec DAO, il s'agit d'une propriété, avec ADO, il s'agit d'une variable passée byref

Je n'ai qu'une seule chose à dire : WAOW !

Merci TOFALU.

Hé bien, si avec tout ça.... il reste quelque chose dans la table. :lol:

Par contre, je ne savais pas que le passage par les Recordset donnait des performances si mauvaises...:(