Add et delete de record qui s'affichent mal

Bonjour,
question sans doute dèjà 1000 fois posée, mais désolé je ne trouve pas la parade.

Le formulaire principal de mon application affiche des "Evènements", basés sur une table Events.

Via un formulaire appelé en cascade, j'importe des évènements complémentaires dans cette table Events, après les avoir effacés au préalable s'ils existent.

Le code fait donc des Delete des anciens records :

Code:

---

1 2 3 4 5 6 7

'Delete Linked Events Entry_Events.FindFirst (Criteria_Events) While Not Entry_Events.NoMatch Entry_Events.Delete Entry_Events.FindNext (Criteria_Events) Wend

---

et des ajouts de nouveaux :

Code:

---

1 2 3 4 5 6 7 8

R_Imports.FindFirst (Criteria_Imports) While Not R_Imports.NoMatch R_Events.AddNew '.... R_Events.Update End If R_Imports.FindNext (Criteria_Imports) Wend

---

En fin de proc je ferme bien tous les recordset et mets bien tous à Nothing.

Mon problème : Quand je reviens sur mon form principal "Events", les record supprimés apparaissent tous avec #delete dans les champs et les nouveaux records ne sont ni comptabilisés, ni visibles.
La méthode requery ne donne rien.
Fermer et rouvrir le formulaire ne donne rien.
Fermer l'application et la rouvrir rectifie l'ensemble.

Comment puis-je faire cela par code sans sortir ?
Faut-il prendre des précautions pour ne pas être dans le formulaire Event sur un record qui va être supprimé, comme par exemple fermer le formulaire et le rouvrir après l'import ?

Merci d'avance.

Bonjour,

As tu essayé de presser la touche F5 ? auquel cas si cela fonctionne il me semble que l'on peut faire quelque chose d'équivalent avec :

Code:

---

docmd.RunCommand.acCmdRefresh

---

A vérifier je ne suis pas sur !

Bon courage

Bonjour,

Juste une petite question toute bête... mais peut être pas...

Ton formulaire est-il directement basé sur la table ou sur un recordset de la table?? Si tel était le cas, il te faudrait recharger le recorset sous-jacent de ton formulaire events afin qu'il prenne en compte les modifications effectuée par le code.

Par contre ce qui cloche dans ce raisonnement est le fait que de fermer et re-ouvrir le formulaire events ne donne rien. Le recordset est pourtant rechargé à ce moment.

Bonjour et merci pour vos réponses.

@JeanYves70.
J'ai testé F5, mais cela ne donne rien.

@GCUSSE
Le form était basé sur la table.
J'ai crée un SQL et l'ai mis à la place comme source.

Fermer et ouvrir le formulaire corrige le problème.

Je voudrais cependant faire ce rafraichissement en automatique par code VBA. Est-ce possible ?

Bon, c'est déjà une bonne nouvelle.... l'update se réalise. On ne solutionne pas mais on contourne... donc c'est fonctionnel.

Pour le rafraichissement, as tu re-essayé le requery? Il devrait fonctionner car il va recharger le recordset.

A la sortie du formulaire d'import tu lui donne un

Code:

---

Forms![NomFormulairePrincipal].requery

---

Absolument.

Je ne faisais pas le .requery de la bonne manière. :aie:

J'ai fait comme tu indiques après les .delete et après les .add.

C'est impec.

Merci beaucoup.

:resolu:

Plutot que de baser le formulaire Events directement sur la table et donc à l'ouverture, pourquoi ne pas baser la source sur l'activation de celui-ci :

Code:

---

1 2 3 4

Private Sub Form_Activate() Me.RecordSource = "SELECT [Events].* FROM [Events];" End Sub

---

Je pense qu'il serait actualisé à chaque "activation" - A voir !

pour le requery:aie: .... ca arrive même aux meilleurs :D

Maintenant si tu veux optimiser, tu n'es pas obligé de faire le requery juste après l'addnew et le delete, mais juste quand tu quittes ton formulaire d'import ou mieux uniquement lorsque que tu reactives ton formulaire principal cf JeanYves70 (avec comme défaut sur le declenchement sur activation, c'est que le requery s'effectuera même si tu n'as rien modifié).

Bref, il ne reste plus que du fignolage...:ccool:

N’empêche, je n'arrive toujours pas à comprendre pourquoi cela ne fonctionnait pas lorsque le forms principal était basé sur la table.... un mystère de plus dans ma connaissance d'access...

Re,

merci pour ses suggestions.

Je me permet de rester sur ma philosophie de .requery après les .delete et après les .add car,

1) Ces 2 fonctions sont des actions/étapes bien spécifiques et distinctes de mon import (2 boutons d'actions différents).

2) Dans le processus d'import, ce traitement de requery est ainsi transparent.

3) Cet import est un traitement annuel alors autant le pénaliser lui plutot que chaque activate du Form principal.


Mes connaissances d'access sont parsemées de trous, mystères et lacunes.

Mais à plusieurs, les trous se compensent.

Encore merci à tous les 2.:ccool: