Discussion :

[=JBO=]

Bonjour,

Mon problème concerne la mise au point d'un Formulaire Access qui permette à un utilisateur de modifier, ajouter, supprimer un ou plusieurs enregistrements puis de décider de valider ou d'annuler l'ensemble des modifications.

En fait, j'aimerai mettre en oeuvre le mécanisme des transactions du moteur JET.

Je ne souhaite pas utiliser une astuce du type table de travail temporaire.

Quelqu'un a-t-il une expérience heureuse ou malheureuse de la combinaison d'un Formulaire et d'une Transaction dans Access?

Toute aide sera la bienvenue,
Merci.

[Tofalu]

Dans ce cas, il te faut un formulaire déconnecté à priori, c'est à dire n'utilisant pas de propriété RecordSource. A moins que tu n'aies un début d'idée avec un formulaire connecté

[=JBO=]

Hello,
Ce qui me séduit dans les transactions, c'est la possibilité offerte par le mécanisme du Rollback qui équivaut à une fonctionnalité d'annulation assez poussée, sans trop de programmation !!!

Dans ce cas, il te faut un formulaire déconnecté à priori, c'est à dire n'utilisant pas de propriété RecordSource.

Hélas, dans une telle configuration, il n'est pas possible d'afficher plusieurs enregistrements... et dans mon "cahier des charges" le formulaire est affiché sous la forme d'une feuille de données pour que l'utilisateur puisse voir un maximum d'enregistrements.

A moins que tu n'aies un début d'idée avec un formulaire connecté

Pour l'instant, sur le plan technique, voilà ce que je pense faire avec DAO:
>> Le Formulaire n'a pas de Recordsource pré renseigné. A la place j'utilise sa propriété Recordset.
>> Référencer l'objet Workspaces(0), sur lequel j'appliquerai la transaction.
>> Référencer l'objet Workspaces(0).Databases(0) pour travailler directement sur la base de données actuellement ouverte dans le Workspace.
>> Créer un objet Recordset basé sur une source de données provenant directement de Databases(0), soit une requête, soit une table.
>> Ouvrir le Formulaire et affecter le Recordset à la propriété Recordset du Formulaire.
>> Débuter une transaction...
>> Permettre à l'utilisateur de faire des modifications directement sur le Recordset sous-jacent au Formulaire.
>> A la fermeture du formulaire, demander de valider les modifications et, en fonction de la réponse, entériner la transaction ou, défaire la transaction.

Utilisation des transactions :
Je sais qu'Access permet de spécifier que l'exécution d'une requête ait lieu au sein d'une transaction...
De manière générale, il est recommandé que la durée d'une transaction de type SGBD soit aussi courte que possible... Or, avec un formulaire, il n'est pas souhaitable de restreindre la durée d'utilisation.

Mais, j'aimerai bien savoir si d'autres ont tenté l'expérience... pour éviter de perdre trop de temps dans une "solution mirage" qui ne conduirait qu'à une impasse.

[Tofalu]

Pour ton cas de figure, c'est exactement ce que j'avais testé avant de poster mon premier message, et ça n'a pas fonctionné. A la différence prés que moi je démarrais la transaction avant l'ouverture du recordset il me semble. A voir

[=JBO=]

OK,
l'utilisation d'une transaction sur la source de données d'un formulaire fonctionne correctement.

J'ai créé un formulaire [Test] qui utilise un recordset "transactionné".
Dans un module de code autonome, la procédure [OuvrirFormTrans] sert à créer le recordset, démarrer la transaction, ouvrir le formulaire [Test] et lui affecter le recordset, et enfin superviser la fermeture du formulaire.

A sa fermeture, le formulaire [Test] demande à l'utilisateur de valider l'ensemble des modifications.
La réponse est transmise à la procédure [OuvrirFormTrans] via la propriété [Form_Rollback]. La transaction est alors entérinée ou révoquée.

Module de code [Test_Transaction]:

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
35
36
Option Compare Database
Option Explicit
 
Dim ws As DAO.Workspace, db As DAO.Database, rs As DAO.Recordset
Dim frm As Access.Form
Dim p_vRollback As Variant
 
Public Property Let Form_Rollback(fValue As Boolean)
    p_vRollback = fValue
End Property
 
Public Sub OuvrirFormTrans()
    p_vRollback = Null
 
    Set ws = Application.DBEngine.Workspaces(0)
    Set db = ws.Databases(0)
    Set rs = db.OpenRecordset("SELECT * FROM Table_Test")
 
    ws.BeginTrans
 
    Set frm = New Form_Test
    Set frm.Recordset = rs
    frm.Visible = True
 
    Do
        DoEvents
    Loop While IsNull(p_vRollback)
 
    If p_vRollback Then
        ws.Rollback
    Else
        ws.CommitTrans
    End If
 
    Set frm = Nothing
End Sub

Module de code du formulaire [Test]:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Option Compare Database
Option Explicit
 
Private Sub Form_Unload(Cancel As Integer)
    Dim Rés As VbMsgBoxResult
    Rés = MsgBox("Valider ?", vbYesNo)
    If Rés = vbNo Then
        Form_Rollback = True
    Else
        Form_Rollback = False
    End If
End Sub

...et merci Tofalu.

[Tofalu]

Ouais mais là tu as une boucle dans le vide

[=JBO=]

Ouais mais là tu as une boucle dans le vide

Non.

Pour sortir de la boucle, il faut que la variable privée [p_vRollback] soit différente de Null.

C'est justement le Formulaire [Test] qui modifie cette variable dans sa procédure événementielle [Form_Unload]. Concrètement, cette procédure assigne une valeur booléenne à la propriété [Form_Rollback] du module de code [Test_Transaction], et la propriété modifie en conséquence la variable [p_vRollback].

Cette nouvelle valeur de [p_vRollback] permet de sortir de la boucle et de choisir d'entériner les modifications ou bien de les révoquer.

C'est vrai qu'il est possible d'éviter une boucle pas toujours élégante et consommatrice de CPU... Mais là je voulais seulement donner ma solution technique... Voilà tout.

[Tofalu]

C'est vrai qu'il est possible d'éviter une boucle pas toujours élégante et consommatrice de CPU... Mais là je voulais seulement donner ma solution technique... Voilà tout

Pas de soucis