Discussion :

[FRED.G]

bonjour,

je deviens fou... J'aimerais gérer mes RecordSet à l'intérieur de transaction.

J'ai donc préparé une classe DataContext pour travailler dans un Workspace donné :

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
37
38
39
40
41
42
43
44
45
46
47
48
Option Compare Database
Option Explicit
 
Private Enum RecordsetLevel
    Parent
    Child
End Enum
 
Private ws As DAO.Workspace
Private db As DAO.Database
 
Private Sub Class_Initialize()
 
    Set ws = DBEngine.CreateWorkspace("ws", "Admin", vbNullString)
    Set db = ws.OpenDatabase(CurrentDb.Name)
    ws.BeginTrans
End Sub
 
Public Function OpenChildRecordset(dataSourceName As String, foreignKey As Long) As Recordset
 
    Set OpenChildRecordset = OpenRecordset(dataSourceName, foreignKey, Child)
End Function
 
Public Function OpenParentRecordset(dataSourceName As String, primaryKey As Long) As Recordset
 
    Set OpenParentRecordset = OpenRecordset(dataSourceName, primaryKey, Parent)
End Function
 
Public Sub RollBack()
 
    ws.RollBack
    ws.BeginTrans
End Sub
 
Public Sub Commit()
 
    ws.CommitTrans
    ws.BeginTrans
End Sub
 
Private Function OpenRecordset(dataSourceName As String, key As Long, level As RecordsetLevel) As Recordset
 
    Dim qdf As DAO.QueryDef
 
    Set qdf = db.QueryDefs(dataSourceName)
    qdf.Parameters(IIf(level = Child, "FK", "PK")) = key
    Set OpenRecordset = qdf.OpenRecordset(dbOpenDynaset)
End Function

J'utilise cette classe comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
'code d'un formulaire qui appel un autre formulaire :
 
Private dc As New DataContext
Private contactEditor As Form
 
Private Sub OuvreForm
    Set contactEditor.Recordset = dc.OpenParentRecordset("RequêteSourceParamétrée", Me.Liste0)
    Set contactEditor.DataContext = dc
    contactEditor.Modal = True
    contactEditor.Visible = True
End Sub

Voici le code du form appelé :

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
Private dc As DataContext
 
 
Public Property Set DataContext(ByRef context As DataContext)
    Set dc = context
End Property
 
 
Private Sub Commande44_Click()
    '
    'Valide les modifications en cours.
    '
    dc.Commit
    Me.Dirty = False
    btcAnnuler.SetFocus
    Commande44.Enabled = False
End Sub
 
Private Sub Commande9_Click()
    '
    'Valide les modifications en cours et ferme le form.
    'Ici le code de fermeture du form suppose que le form soit l'objet actif
    '
    dc.Commit
    DoCmd.Close
End Sub
 
Private Sub btcAnnuler_Click()
    '
    'Ici le code de fermeture du form suppose que le form soit l'objet actif
    '
    DoCmd.Close
End Sub

Voilà, je deviens fou parce que j'ai bien fait attention de créer une transaction quand j'initialise ma classe DataContext, ensuite je travaille toujours avec la même instance de DataContext, mon recordset est créé par DataContext, donc devrait être soumis à la transaction.

Or, que je commit ou non, les données sont toujours enregistrées...

[mout1234]

Salut,

Je ne suis pas sur mais... je ne pense pas que tu puisses utiliser dans ce cas un formulaire dépendant d'une source... peux-tu faire un form indépendant (et donc gérer par code la databinding...)?

[FRED.G]

Si si, il est possible d'utiliser des forms dépendants en définissant soi-même son Recordset.

La limite d'Access réside apparemment dans le fait qu'un Recordset ouvert après le début d'une transaction n'est pas soumis à celle-ci. Ce que je trouve TROP NUL.

Il faut créer la transaction après avoir ouvert le Recordset. Ce qui enlève de belles possibilités...

[mout1234]

Surprenant...


Pourquoi dans ce cas ne pas ajouter une méthode BeginTrans à ta classe...?

[FRED.G]

Tu as raison. A première vue cela ne me plaisait pas, d'une part, parce que le nombre de transactions est limité (5 d'après la doc, 6 ou 7 d'après mes tests), d'autre part, parce que ça complique un peu le code, tout simplement.

Mais je n'ai pas le choix, et si je m'en sors avec des transactions imbriquées, ben ce sera déjà pas mal.

[mout1234]

Je viens d'essayer en ajoutant une méthode BeginTrans et supprimant le begintrans de l'init de la classe...

puis en lançant simplement la transaction une fois l'association effectuée... ça semble marcher ...

Code :

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

1
2
3
4
 
    Set contactEditor.Recordset = dc.OpenParentRecordset("RequêteSourceParamétrée", lgKey)
    Set contactEditor.DataContext = dc
    dc.BeginTrans

Sympa ta classe,... c'est quoi ton objectif au juste?

[FRED.G]

Je viens d'essayer en ajoutant une méthode BeginTrans et supprimant le begintrans de l'init de la classe...

puis en lançant simplement la transaction une fois l'association effectuée... ça semble marcher ...

Oui tout à fait. J'avais fait un test similaire en déplaçant le begintrans de l'init de ma classe dans sa la sub OpenRecordset. Ce qui revient au même.

En fait, je veux créer des forms de saisie sous forme de boite de dialogue, permettant à l'utilisateur de modifier :
- un enregistrement donné (l'enregistement affiché dans la boite de dialogue)
- ses enregistrements enfants (affichés eux aussi dans la boite de dialogue via des sous formulaires)
- les enregistrements parents (sélectionnés et affichés à la demande dans de nouvelles boites de dialogues).

Le tout sachant que je veux respecter le principe habituel des boites de dialogue windows, à savoir qu'elles présentent en pied de formulaire les boutons :
- Annuler
- OK
- Appliquer

Sachant que le 'Appliquer' est réservé aux boite de dialogue "racine", c'est à dire que toute boite de dialogue "secondaires" ouverte à partir de la boite de dialoge racine permet de valider et fermer (= OK) OU d'annuler et fermer (= Annuler), mais pas de valider en cours de saisie car leur modifications sont soumises à la validation globale de la boite de dialogue racine.

Or je me suis dit dans un premier temps qu'il suffisait d'ouvrir ma boite de dialogue racine dans un Workspace dédié, de démarrer aussitôt ma transaction, puis d'ouvrir toute boite de dialogue secondaire dans le même Workspace, sous la même transaction...

Tu me vois venir... L'utilisateur fait ses modifs (ajouts, suppression, édition...), puis s'il décide d'annuler ses modifs, moi je n'ai rien à coder. S'il veut enregistrer, je fait juste un DataContext.Commit.

Sauf que, comme tu l'as testé toi-même, je ne peux pas juste ouvrir une seule transaction pour tous mes recordest (sachant que ceux-ci ne sont pas tous ouverts d'un coup mais au gré des choix (facultatifs) de l'utilisateur). donc j'ai eu un peu peur à l'idée de devoir ouvrir presqu'autant de transaction que de recordset, mais en fait je suis sauvé par 2 trucs je pense :

- les recordset de sous formulaires sont traités en même temps qu'un recordset parent (donc j'ai une unité, qui correspond d'ailleurs à une boite de dialogue) --> là il me faut une transaction par boite de dialogue.

- étant donné que j'utilise des boites de dialogue modales, chaque transaction imbriquée imposée par cette boite disparait avec elle. Donc je me retrouve potentiellement avec au moins 5 niveaux d'ouverture de boite de dialogue. Ce qui est amplement suffisant pour perdre l'utilisateur.
Au niveau du codage de ma classe DataContext et de son utilisation, le fait de devoir utiliser des transactions imbriquées ne devrait pas poser de pb dans la mesure où j'utilise des boites modales, car chaque appel beginTrans ou Commit ou RollBack, pourvu qu'il soit fait à l'ouverture/fermeture des boites modales, fera nécessairement appel à la bonne transaction : à savoir la dernière en cours.

Voilou.

[mout1234]

Si je comprends bien ton code, tu crées donc une séquence de transcations qui englobent chacune toutes les opérations effectuées dans les formulaires entre chaque validation (Commit via le bouton Appliquer).

Mais dans ce cas, comment tu annules ... (je n'ai pas vu d'appel au RollBack dans ton bouton Annuler...)

Et comment tu fermes la dernière transaction ouverte? ton datacontext ne comporte pas de méthode permettant de fermer sans rouvrir... un simple Rollback dans le terminate suffirait, non ?

J'ai refait un essai (un peu trop rapide pour être fiable...) et j'ai pu annuler (sans avoir déplacé le begintrans comme évoqué précédement...) le problème ne vient donc peut être pas exactement de là où tu le pensais...

Par contre mon essai était plutot instable il me refusait une fois sur deux le rollback (ne trouvant pas le begintrans correspondant...) ...



La création d'un Workspace est interessante sur le plan conceptuel pour en quelque sorte encapsuler les opérations de données... mais il n'est pas indispensable vu que tu travailles dans une série de form en modal... si tu traites directement avec la worksapce courant cela éviterait la surcharge par un nouveau Workspace.... et logiquement toutes tes sources (sans même être obligé de les attribuer dynamiquement) sont intégrées à la transaction... Ton datacontext se transformer en un pilote de transaction... plus simple non?

[FRED.G]

Salut,

Mais dans ce cas, comment tu annules ... (je n'ai pas vu d'appel au RollBack dans ton bouton Annuler...)

Et comment tu fermes la dernière transaction ouverte? ton datacontext ne comporte pas de méthode permettant de fermer sans rouvrir... un simple Rollback dans le terminate suffirait, non ?

En fait, l'appel du RollBack est implicite lors de la fermeture du workspace. C'est le commit qui doit être explicite.

J'ai refait un essai (un peu trop rapide pour être fiable...) et j'ai pu annuler (sans avoir déplacé le begintrans comme évoqué précédement...) le problème ne vient donc peut être pas exactement de là où tu le pensais...

Oui tout à fait, tu as raison. Hier je me suis rendu compte que j'avais mal codé ma mise à jour en ne rafraichissant pas le formulaire avant le commit, ce qui donnait des mises à jour un peu aléatoires . Pour reprendre le code précédent (du form appelé), voici comment il pourrait être corrigé :

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
Private Sub Commande44_Click()
    '
    'Valide les modifications en cours.
    '
    Me.refresh
    dc.Commit
    btcAnnuler.SetFocus
    Commande44.Enabled = False
End Sub
 
Private Sub Commande9_Click()
    '
    'Valide les modifications en cours et ferme le form.
    'Ici le code de fermeture du form suppose que le form soit l'objet actif
    '
    Me.refresh
    dc.Commit
    DoCmd.Close
End Sub

Si je comprends bien ton code, tu crées donc une séquence de transcations qui englobent chacune toutes les opérations effectuées dans les formulaires entre chaque validation (Commit via le bouton Appliquer).

Au départ, l'utilisateur ouvre un form (appelons-le form "de sélection") qui permet via une liste filtrée de sélectionner un enregistrement. Ce form n'est pas lié ni modal. Lorsque l'utilisateur veut éditer le détail de l'enregistrement sélectionné, c'est là que démarre la saisie modale sous transaction.
A savoir que j'ouvre une boite de dialogue liée (qualifions-la de "principale") affichant le détail de l'enregistrement (qualifions-le de "principal" également) ainsi que ses enregistrements "enfants" via des sous forms liés.
Cette boite de dialogue possède le bouton 'Appliquer'. A partir de cette fenêtre, je peux décider d'en ouvrir d'autres "secondaires" afin par exemple de sélectionner un enregistrement parent de l'enregistrement principal (imagine par exemple une table 'Personnes' où chaque entité possède un père et une mère définis dans la même table --> si l'utilisateur veut définir le parent, là carrément je vais créer une nouvelle instance, modale, de mon form "de sélection", puis si l'utilisateur le demande, une nouvelle instance de mon form de saisie détaillée qui sera a même classe que celle de ma fenêtre "principale"). Mais ces fenêtres là n'ont pas de bouton 'Appliquer'. En effet, soit on annule, soit on valide, sachant que toute modification faite reste soumise à la validation de la boite de dialogue principale (celle de l'enregistrement principal) via ses boutons 'OK' ou 'Appliquer'. Tu vois mieux le truc ?

La création d'un Workspace est interessante sur le plan conceptuel pour en quelque sorte encapsuler les opérations de données... mais il n'est pas indispensable vu que tu travailles dans une série de form en modal... si tu traites directement avec la worksapce courant cela éviterait la surcharge par un nouveau Workspace.... et logiquement toutes tes sources (sans même être obligé de les attribuer dynamiquement) sont intégrées à la transaction... Ton datacontext se transformer en un pilote de transaction... plus simple non?

Je n'ai jamais envisagé de créer plusieurs Workspace, au contraire. J'ai cru par contre être obligé de créer plusieurs transactions imbriquées. Mais d'après nos derniers tests une seule devrait suffir.
Quant à l'utilisation de fenêtres modales, c'est avant tout un choix ergonomique.

[FRED.G]

J'ai cru par contre être obligé de créer plusieurs transactions imbriquées. Mais d'après nos derniers tests une seule devrait suffir.

En fait, je vais quand même conserver le principe de transactions imbriquées. Je le dois si je veux pouvoir annuler les saisies "secondaires" à leur niveau et pas seulement au niveau de la fenêtre "principale"...

[mout1234]

En fait, l'appel du RollBack est implicite lors de la fermeture du workspace. C'est le commit qui doit être explicite.

Je vois masi je préfère écrire explicitement ce genre de traitement... ne serais-ce que pour une question de lisibilité...

partir de cette fenêtre, je peux décider d'en ouvrir d'autres "secondaires" afin par exemple de sélectionner un enregistrement parent de l'enregistrement principal ...
je vais créer une nouvelle instance, modale, de mon form "de sélection" ...

Cela supposerait donc que ton form de sélection soit lui aussi lié au datacontext.

Tu vois mieux le truc ?

C'est à peu prés ce que j'imaginais au début... mais je ne suis toujours par convaincu que tu ais besoin de créer un nouveau worksapce....


Je suis généralement prudent dans l'utilisation de transactions d'Access. J'ai eu plusieurs fois des problèmes de limites ... typiquement lorsque je souhaitais englober des processus d'importation de données ... bien souvent il n'arrivait pas à tout digérer et j'étais obligé d'abandonner les transactions et coder autrement des moyens de retour en cas d'annulation d'import... Il ne faut pas oublier qu'Access est certes un trés bon produit qui déjà pas mal de choses... mais ce n'est pas un service server type SQL Server
Outre le fait que ton interface demandera une certaine concentration aux utilisateurs pour en tirer pleinement profit, je suis curieux de voir comment tu peux aboutir à qq chose de stable et fiable... d'autant que tu vas j'imagine démultiplier par la même occasion des instances de form...

[FRED.G]

Je vois masi je préfère écrire explicitement ce genre de traitement... ne serais-ce que pour une question de lisibilité...

Certes. En même temps une ligne de commentaire pour expliquer la chose me parait assez explicite dans ce cas, même s'il se trouve que dans la version actuelle du code, j'utilise systématiquement des RollBack. Je t'avoue en tout cas que je n'aime pas le modèle de gestion des transactions DAO (par rapport à celui de ADO.NET), donc si je veux faire vraiment bien, autant pas utiliser Access...

Cela supposerait donc que ton form de sélection soit lui aussi lié au datacontext.

Il l'est.

C'est à peu prés ce que j'imaginais au début... mais je ne suis toujours par convaincu que tu ais besoin de créer un nouveau worksapce....

Ben je le répète, je n'ai jamais envisagé de créer plusieurs workspace.

Je suis généralement prudent dans l'utilisation de transactions d'Access. J'ai eu plusieurs fois des problèmes de limites ... typiquement lorsque je souhaitais englober des processus d'importation de données ... bien souvent il n'arrivait pas à tout digérer et j'étais obligé d'abandonner les transactions et coder autrement des moyens de retour en cas d'annulation d'import... Il ne faut pas oublier qu'Access est certes un trés bon produit qui déjà pas mal de choses... mais ce n'est pas un service server type SQL Server

Je n'ai jamais eu à pousser Access dans ses limites et je ne m'inquiète pas trop pour ce que je vais faire : éditer manuellement des enregistrements liés par des relations un à plusieurs. Si Access peut pas faire ça, faut le jeter à la poubelle.

je suis curieux de voir comment tu peux aboutir à qq chose de stable et fiable... d'autant que tu vas j'imagine démultiplier par la même occasion des instances de form...

Oui je vais instancier des forms, mais où est le souci en terme de stabilité ?

ton interface demandera une certaine concentration aux utilisateurs pour en tirer pleinement profit

Peux-tu m'expliquer plus en détail pourquoi ?
Franchement tu m'as mis le doute...
Il me paraissait logique que toute fenêtre modale ouverte à partir d'une autre fenêtre modale soit dépendante du commit de cette dernière.
Regarde par exemple sous XP (cf. PJ).
Dans les propriétés d'affichage, si tu ouvres la fenêtre pour modifier les effets et cliques sur OK, ces modifs ne seront enregistrées que si tu valides (via OK ou Appliquer) dans la première fenêtre.

J'étais partis sur ce principe... Mais je crois que dans le cas d'édition d'enregistrement, je devrais autoriser le commit définitif au niveau de chaque fenêtre elle-même. L'unité "fenêtre" (pour valider ou annuler des modifs) est sans doute plus simple, que l'unité "hiérarchie de fenêtre" (où la validation ou annulation définitive de toutes les fenetres dépend de la première)...

Je pense que vais m'orienter dans ce sens. Pour reprendre l'exemple XP, ce cas est représenté par exemple si on fait Affichage / Paramètre / Avancé.

Cela impose par contre de créer un Datacontext (=Workspace) par fenêtre. Mais ça ne me dérange pas, Access ne me laisse pas le choix. L'autre avantage de cette façon de faire est que je ne serais pas limité dans le nombre de mes transactions.

[mout1234]

Il me paraissait logique que toute fenêtre modale ouverte à partir d'une autre fenêtre modale soit dépendante du commit de cette dernière.

C'est vrai ... je suis sans doute habitué à développer pour un public peu averti ... mais je pense tout de même que la démuliplication de fenêtres dont les modifications sont dépendantes risque d'être un peu piégeante non? Ton exemple dans Wds XP vas bien parce que tu n'as qu'un ou 2 niveaux de cascade...
En tout cas il faudrait que visuellement la fenêtre racine soit clairement identifiable comme une fenêtre principale de laquelle dépendent toutes les fenetres ouvertes...
Quand tu parles de pouvoir aussi bien atteindre un enregistrement fils qu'un parent ... au bout d'un moement il sera difficie de se souvenir / identifier le point de départ des modifs...

Enfin bon, je n'ai pas ton appli en tête ... mon imagination la déforme sans doute ...

Bon courage dans ton projet...

Laisses nous de temps en temps des news sur l'avancement, tes déboires et tes brillantes idées

[FRED.G]

Je suis tout à fait d'accord avec toi. J'ai donc décidé de gérer mes transactions au niveau des fenêtres.

Laisses nous de temps en temps des news sur l'avancement, tes déboires et tes brillantes idées

Côté déboire, y a le fait que la méthode requery n'est pas supportée par les transactions. Donc difficile de rafraichir correctement les fenêtres. De là à ce que je me rendre compte que fermer un Recordset ferme automatiquement la transaction en cours, il n'y a peut-être qu'un pas... Je pressens le pire ! lol

[mout1234]

Je reste convaincu qu'il serait plus facile de gérer tout ca avec des formulaires indépendants et gérer toi-même le databinding... au moins tu maitrise exactement ce qui se passe ... masi bon si tu as aussi des sf en continu .. ca se corse...

[FRED.G]

J'étais exactement en train de me faire cette réflexion. Ceci dit, mon code a l'air au point et pas trop compliqué à mon goût.

Pour la question du rafraichissement des (sous) forms en continu, ce n'est pas un trop gros problème.
En effet, de deux choses l'une :

- soit le recordset est en lecture/écriture : dans ce cas il est soumis à la transaction et je ne peux pas faire de Requery. Mais je n'ai pas besoin de faire de requery car il me suffit de faire mes insertions / suppression / update directement dans ce recordset.

- soit le recordset est en lecture seule. Là je peux avoir besoin d'un requery, et pour cela le recordset ne doit pas être soumis à la transaction. Mais cela n'est pas un pb puisqu'un recordset en lecture seule n'a pas besoin de transaction...

Donc je m'en sors très bien. A vrai dire, le truc le plus chiant dans ma stratégie n'est pas dû aux transactions (qui jouent bien leur rôle), mais au problème inhérent à tout form de saisie dépendant : si l'enregistrement ne respecte pas les règles de validation et que l'utilisateur cliques sur le bouton système 'Fermer' du form, je dois gérer l'affaire avec deux msgbox successives, comme le fait Access lui-même, ce qui est nul, mais c'est du Access, donc à prendre ou à laisser...

[mout1234]

je dois gérer l'affaire avec deux msgbox successives,

Ca on peut en général régler le problème en topant cette cascade dans un booléen en propriété privée du form... de façon à rendre silencieux le 1er message si on est dans une logique de sortie...

[FRED.G]

Oui, sauf que tu ne peux pas détecter si tu es dans une logique de sortie lorsuqe l'utilisateur passe par le menu système du form. Or je ne veux pas me passer du menu système.

[mout1234]

?
Si tu centralises tes traitement sur l'event Form_Close, ça intercepte aussi la fermeture via le menu système non?

[FRED.G]

Pour mémoire, les erreurs (et donc les 2 messages) surviennent au moment du Refresh, avant les événement de fermeture (Unload / Close).