Discussion :

[stéphane_ais2]

Bonjour,

J'utilise un frm indépendant associé à un sous frm pour saisir de nouvelles données.
Les données sont enregistrés dans les tables ad hoc par du code Vba.

Pour des raisons pratiques j'ai souhaité utiliser ce même frm toujours associé au même sous-frm pour effectuer des consultations, des modifications et des suppressions.
Pour cela, j'ai attribué aux deux frm (Main et sub) une source de données basée sur deux tables temporaires.

A l'ouverture de ces deux objets, l'utilisateur ne peut rien modifier. Pour cela, il doit cliquer dans une zone de texte et le frm principal et le sous frm deviennent modifiables.
La modification est validée par un bouton 'Modifier' qui sur l'évenement 'clic' propose ou non de valider les modifications apportées.
Je ne parviens pas, lorsque l'utilisateur choisit de ne pas valider ses modifications, à rétablir dans les contrôles du frm principal et du sous frm les valeurs initiales d'avant la modifications.

J'ai essayé la méthode 'RunCommand acCmdUndo'? Elle renvoie une erreur qui suggère qu'un évenement BeforeUpdate est en cours (sûrement relatif aux modifications du sfrm)...le btn 'Modifier' se trouvant sur le frm principal.

J'ai lu de nombreux posts sur des sujets proches et notamment celui-ci :
http://www.developpez.net/forums/sho...highlight=undo
qui m'a inquiété et notamment la réponse #11 avec comme point d'orgue cette réflexion dont je me sens très proche :

Cela pose de très nombreux problèmes complexes auxquels je ne m'attendais pas du tout

Je souhaite garder l'interface actuelle, un btn 'Modifier' qui valide ou non les changements et ne pas intervenir directement sur les évenements BeforeUpdate des deux frms.
J'ai pensé aussi "réinjecter" les valeurs des tables temporaires dans les contrôles...sans l'avoir testé encore.

Je mets le code actuel :

Code :

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

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
26
27
28
29
30
31
32
33
34
 
Select Case MsgBox("Les modifications seront définitives. Voulez-vous continuer ?", vbYesNo Or vbCritical Or vbDefaultButton1, "ATTENTION : Action irréversible")
 
    Case vbYes
        'enregistre les données du frm pour éviter
        'le conflit d'écriture avec le code de mise
        'à jour qui suit.
        DoCmd.RunCommand acCmdSaveRecord
 
        With tbl
            .Edit
            ![fa_titre_responsable] = cboCivilite
            ![fa_nom_responsable] = txtNom
            ![fa_adresse_1] = txtAdresse
            ![fa_commune] = cboCommune
            .Update
        End With
        With tblEl
            .Edit
            ![el_nom] = sf("txtElNom")
            ![el_prenom] = sf("txtElPrenom")
            ![el_ddn] = sf("txtDdN")
            ![el_sexe] = sf("cboElSexe")
            .Update
        End With
 
        Call MsgBox("Les modifications demandées ont été effectuées avec succès.", vbInformation, "Procédure terminée")
 
    Case vbNo
        DoCmd.RunCommand acCmdUndo
 
        Call MsgBox("Les modifications ont été annulées.", vbInformation, "Procédure annulée")
 
    End Select

Merci par avance pour vos avis.

SE

[DelphiManiac]

Malheureusement, je te conseillerrais de ne pas perséverer dans ce sens. Access apporte énormément de choses intéressante tant que tu restes dans le mode de fonctionnement d'access. Des que tu essayes de trop outrepassé le fonctionnement standard, tu te trouves face a des problèmes continuel.

Un exemple par rapport à ce que tu donnes : tu dis, je ne veux que l'utilisateur ne puisse valider que par le bouton 'Modifier'.

Comment va tu empoécher l'enregistrement automatique que fais access des que tu fermes le formulaire ?

Les touches F9 et ctrl+entrée provoque aussi l'enregistrement des données. Le défilement dans le recordset va te poser des problèmes aussi.


Si tu tiens vraiment à coder "à la main", fait le entièrement, controle entièrement indépendant que tu remplis à chaque appel de fonction, lecture, modification, suppression, etc....

Si tu persistes dans cette voie je te souhaite bien du courage.

[stéphane_ais2]

Merci pour ta réponse.
Ce choix de développement offre à mes yeux plus d'avantages que de problèmes soulevés.
Celui que je soumets aujourd'hui ne doit pas être insurmontable même si j'échoue à le résoudre encore.
La gestion des risques que tu envisages (contrôle de l'enregistrement) passe par l'interface proposée à l'utilisateur et ce qui lui est possible de faire ou pas selon l'état de la procédure dans laquelle il se situe.
Je te rejoins cependant sur le point de travailler sur des forms complétement indépendants et pas comme je tente de le faire sur ce cas précis en attribuant un recordSource au formulaire. Ce qui est déjà une bonne piste...

SE

[=JBO=]

Bonjour,

Je te rejoins cependant sur le point de travailler sur des forms complétement indépendants et pas comme je tente de le faire sur ce cas précis en attribuant un recordSource au formulaire. Ce qui est déjà une bonne piste...

Il y a quelques temps, j'avais planché sur un Pb du même ordre, voire un peu plus complexe, puisqu'il était possible d'annuler des modifications apportées à plusieurs enregistrements.

Ma solution était basée sur un Form dépendant d'un Recordset assigné "à la main" et "protégé" par une transaction.
http://www.developpez.net/forums/showthread.php?t=71989

[Muhad'hib]

Salut,

J'utilise une méthode similaire :

mon formulaire principal est indépendant. Je charge les données de l'enregistrement ciblé par code (ouverture d'un recordset, affectation aux différents contrôles de la valeur d'un champ). Pour les sous formulaire, j'utilise une table temporaire (par code j'y mets les enregistrements dont j'ai besoin)

Sur validation des modif, je modifie mon recordset avec les valeurs des contrôles et de la table temporaire.

En cas d'annulation, je réutilise simplement la fonction qui initialise le formulaire et le sous-formulaire.

Je sais que ce n'est peut-être pas l'idéal d'un point de vu ressource et concept, mais comme je ne maitrise pas les transactions, c'est la méthode que j'ai retenu.

A+

[stéphane_ais2]

Bonjour et merci pour vos réponses et suggestions

Je vais privilégier aujourd'hui la proposition de Muhad'hib qui fonctionne très bien et garder pour bientôt l'idée des transactions que je ne connaissais pas (entre autres choses d'ailleurs... )

Merci encore

SE