Discussion :

[jppaysan]

La FAQ dit que pour empêcher ACCESS d'enregistrer de lui-même les modifications/ajouts d'enregistrements du formulaire il faut :

• créer un formulaire non lié (ou indépendant),
• créer un recordset
• afficher les données du recordset dans le formulaire.

Créer un formulaire et un recordset : pour moi ça va.
Là ou cela ne va plus c'est quand j'ajoute les données du recordset dans les contrôles (ou champs du formulaire) du formulaire je vois qu'un enregistrement (le dernier) alors que je sais qu'il y en a 3.
Je précise que mon formulaire est défini en mode continu.

Question : comment fait-on pour afficher les enregistrements d'un recordset dans un formulaire non lié défini en mode continu ?

Au départ j'étais tenté d'utiliser une table temporaire sur laquelle j'aurai lié mon formulaire au travers d'une requête. Mais j'ai pensé que créer une table temporaire serait très lourd d'autant que mon appli est destinée à être mise en réseau pour un usage multi-utilisateur. Par hazard en naviguant sur le forum j'ai vu apparaitre la notion de table attachée. Qu'est-ce ?? et comment implémente-t-on cela sous ACCESS ?

Merci d'avance.

[jppaysan]

Petit complément à mon message précédent.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Private Sub Form_Open(Cancel As Integer)
Dim sSQL As String
Dim oQryDef As DAO.QueryDef
Dim oRst As DAO.Recordset
 
' sSQL est une chaîne de caractères contenant une requête SQL qui extrait des enregistrements d'une table
 
Set oQryDef = CurrentDb.CreateQueryDef("", sSQL)    ' Crée une requête temporaire
Set oRst = oQryDef.OpenRecordset(dbOpenDynaset, dbDenyWrite, dbOptimistic)
 
Form.AllowAdditions = True
Set Me.Recordset = oRst
Sub

Le code ci-dessus me permet effectivement d'afficher dans un formulaire le contenu du recordset. C'est vrai qu'au départ le formulaire n'est pas lié à une table ou une requête mais le simple fait d'écrire la ligne de code :

Code :

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

Set Me.Recordset = oRst

lie à nouveau le formulaire à la table. Je l'ai constaté en mode débug en regardant les propriétés du recordset du formulaire. De plus si je modifie une valeur dans le formulaire celle-ci est immédiatement répercutée dans la table qui lui est liée. Or ce n'est pas du tout ce que je souhaite.

Je veux vraiment pouvoir modifier/ajouter/supprimer des enregistrements dans un formulaire indépendant sans que la table d'où ils proviennent soit constamment mise à jour.

Merci d'avance. J'attends avec impatience vos propositions :

[stéphane_ais2]

Salut,

Peut-être que tu as déjà vu ce topic...
http://www.developpez.net/forums/vie...aire+mise+jour
Si ce n'est pas le cas, regarde ce que dit DonFelipe...
Cela si j'ai bien compris ta demande peut te donner une orientation :

SE

[jppaysan]

stéphane_ais2, j'ai lu le "topic" que tu m'adresses. La solution de la table temporaire m'intéresse énormément mais le "topic" ne me donne que la moitié de la réponse et la moitié qui n'est pas expliquée est celle que je recherche.

Je m'explique. Je suis d'accord pour créer une table temporaire. Cependant :

• Comment fait-on pour coder cela en VBA?
• Est-ce que cette table dite temporaire apparaîtra physiquement au niveau de la base de données ou restera-t-elle simple au niveau du code VBA ? (je dis cela par rapport à un environnement multi-utilisateur : si elle reste au niveau du code VBA il n'y a pas de souci particulier; par contre si elle apparaît au niveau de la base de données il y a risque d'erreur, de conflit, lorsque chaque opérateur voudra créer depuis son PC la même base de données).
• Est-ce une simple copie de la table originale ? si oui, dans le cas où la table contient des millions d'enregistrements, la copie va engendrer des millions de transferts sur le réseau => est-ce vraiment optimum et comment fait-on cette copie? si non est-ce que cela signifie qu'il faut créer dans du code VBA une table en définissant 1 par 1 tous les champs avec leurs propriétés ==> fastidieux non ?
• Au moment où l'on veut créer la table temporaire, n'y-a-t-il pas un moyen pour ne copier que le ou les enregistrement(s) qui nous intéresse(nt)? Si c'est possible comment fait-on ?
• Par ailleurs si l'on est conduit à supprimer un enregistrement de la table temporaire, comment fait-on lors de la mise à jour de la table originale, pour savoir quel enregistrement a été effacé ?

Je rappelle qu'à terme mon application sera sur réseau en multi-utilisateur.

J'espère avoir été clair dans l'exposition de mon problème.

Encore merci d'avance.

[Tofalu]

Une autre possibilité, utiliser quelque chose de semblable à ceci :

http://warin.developpez.com/access/d...=partie_5#L5.5

Reste à coder les ajouts et modifications. Mais ceci n'est pas bien compliqué et tu trouveras ton bonheur dans le tutoriel incluant l'exemple ci-dessus

[jppaysan]

Tofalu j'ai bien lu le chapitre 5-5 que tu m'indiques. Mais là encore on ne parle que dans le cas de lecture. Dans le cas de modifications ou d'ajouts d'engristrements dans le recordset ces opérations seront répercutées immédiatement sur la table à laquelle il est associé. ET ça je veux le maitriser.

Je pense que ma solution réside dans l'écriture de code VBA pour la création d'une table dans laquelle je recopierai les enregistrements souhaités. Ceci est contenu dans toutes les questions de mon précédent message.

Dans l'attente de réponses la part du forum...

[Tofalu]

Dans le cas de modifications ou d'ajouts d'engristrements dans le recordset

Evidement puisque le recordset est la table.

Donc ajouter des données dans une table est inévitablement répercuté dans la table. C'est une question de pure logique. Peint la carrosserie de ta voiture en rouge, ta voiture sera rouge.

Le seul moyen est dans ce cas d'utiliser les transactions, mais ça ne semble pas coller à ce que tu veux. Je crois que tu n'as pas compris la notion de recordset, car dans l'exemple 5.5, les zones de texte sont indépendantes, ce que tu écris dedans n'est pas répercuté sur les données directement

[jppaysan]

Tofalu, je pense avoir compris la notion de recordset. Par contre là où je fais une erreur dans ma conception c'est que je veux utiliser (pour m'éviter d'écrire du code) un recordset pour stocker les modifications faites sur les données affichées par le formulaire. Et évidemment toute modification dans le recordset est répercutée sur la table associée.

Donc aujourd'hui il faut que je vois comment faire. Je me trouve dans une impasse.
Ma conception était la suivante :

• j'ai des tables dans lesquelles je stocke mes enregistrements
• j'ai créé un table copie conforme à l'originale dans laquelle je stocke le ou les enregistrements sur lequel(s) je veux travailler. Ainsi je maitrise les modif/ajouts/suppression sur les enregistrements avant de remettre à jour la table originale.

Là je me suis dit que cette solution de table transitoire ne pouvait pas fonctionner dans un environnement multi-utilisateurs puisque plusieurs utilisateur ne pouvaient pas utiliser cette même table transitoire. C'est à partir de là que j'ai commencé à cogiter pour aboutir aujourd'hui dans une impasse.

Si je me suis fait comprendre et surtout si quelqu'un à une solution

[Tofalu]

Je ne vois pas en quoi le recordset va résoudre le problème.

Un formulaire indépendant c'est un formulaire sans recordset. En fait, il s'agit juste d'un objet form. Tu n'utilises donc pas le databinding (liaison avec les données) des controles. Dés lors, en aucun cas ce qui est tapé dans les zones de textes par l'utilisateur n'impacte les données et ce tant que tu n'en a pas donné l'ordre via des requêtes UPDATE.

Ce que tu peux faire dans ton application puisque tu sembles désireux d'utiliser les tables temporaires c'est de placer la table temporaire dans l'application frontale (celle installée sur chaque poste client) et non sur la dorsale (celle qui se trouve sur le serveur). Du coup, les modifications opérées par un utilisateur ne concernent que lui. Ensuite, via une requête update, tu mets à jour les données. Toutefois, cette architecture est exclusivement compatible avec des tables dont la clé primaire est technique et non pas fonctionnelle. Car si les utilisateurs peuvent modifier la valeur de la clé primaire, tu risques d'écraser des données exsitantes avec tes requêtes UPDATE. Et là c'est tout la cohérence de ta base de données qui prend l'eau

[Muhad'hib]

Tu peux aussi gérer ta structure pour que l'utilisateur ne puisse pas toucher aux clefs primaires.
Mais comme Tofalu l'a bien expliqué pour utiliser les tables temporaires il faut que l'appli soit scinder en 2, ce qui ne semble pas être ton cas :

Est-ce que cette table dite temporaire apparaîtra physiquement au niveau de la base de données ou restera-t-elle simple au niveau du code VBA ? (je dis cela par rapport à un environnement multi-utilisateur : si elle reste au niveau du code VBA il n'y a pas de souci particulier; par contre si elle apparaît au niveau de la base de données il y a risque d'erreur, de conflit, lorsque chaque opérateur voudra créer depuis son PC la même base de données).

Si ton appli est multi-utilissateur il est vraiment conseillé d'utilliser une structure comme celle décrite par Tofalu.