Discussion :

[Smint]

Salut tous,

Dans une table contenant x enregistrements, si je saisis une date dans un champ du premier, comment reproduire cette valeur automatiquement sur toute la colonne ?

Merci, bonne reprise….. .

[Papy Turbo]

2 méthodes :
- soit tu saisis la nouvelle valeur dans un contrôle indépendant, et tu lances une requête SQL de type Mise à jour (UPDATE) qui écrit cette valeur dans le champ de toute la table (<- la + rapide)
- soit tu fais une boucle en VBA, avec DAO, sur tous les autres enregistrements de la table (ou du RecordsetClone du formulaire ), et tu colles la valeur dedans.

Avec laquelle es tu le plus à l'aise ?

[Smint]

Salut Papy Turbo

Je ne suis à l'aise ni avec l'un, ni avec l'autre pour ne pas dire que c'est quasiment du chinois pour moi.... Je ne possède que les bases Access, mais dès que l'on touche au code, c'est autre chose.... Mes souvenirs lointains de la programmation en basic ou dBase3 ne sont pas suffisants....

Heureusement, j'apprends vite et j'ai déjà fait énormément de progrès grace à ce forum puisque j'ai réussi à insérer des codes du type "blocage de la roulette" dans les formulaires, gestion des focus par évènements...

Voilà pour ce qui est de mon niveau.

Dommage que la recopie vers le bas, de type Excel ne fonctionne pas sous Access....

[random]

Code :

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

1
2
3
 
PARAMETERS [entrez une date] DateTime;
UPDATE matable SET matable.[date] = [entrez une date];

tu fais requête nouveau
affichage sql
tu colles le code ci dessus
tu remplaces matable et date par le nom de ta table et de ton champ

[Smint]

Salut Random,

Merci de ta réponse.

Le seul souci avec ce type de solution, si je la comprends bien, c'est que cela suppose que l'on ait une table enregistrée comme objet, ce qui n'est pas le cas puisque la table en question est le produit d'une requête sélection....

Alors, me direz-vous, une simple requête de mise à jour suffirait... oui, sauf que je voudrais trouver une autre solution. En effet, ma requête sélection comporte de nombreux critères qui sont saisis au lancement. Le but est de tester différentes hypothèses et rechercher la meilleure solution... Si je fais une requête de mise à jour, les critères me sont redemandés... Une erreur, une inattention et ma base est pourrie... Je voudrais, pour ça, travailler sur la table même, sans lancer d’autres requêtes…

Si le rechercher/remplacer fonctionnait, je pourrais faire comme ça mais, le champ étant vide, la recherche ne fonctionne pas, ni avec « Null », ni avec « Est Nul »… .

A l’idéal, je saisis la date qui m’intéresse dans le champ de l’enregistrement 1, puis, lancement d’une macro.. Et hop! ….

[Papy Turbo]

Excuse, c'est de + en+ confus pour moi.
Tu veux copier une valeur dans un champ de :
- toute une table, (laquelle ? comment elle s'appelle ? quel champ ? date de quoi ?)
- seulement ceux qui sont sélectionnés dans le formulaire ?

Avec des noms, stp, qu'on sache de quoi on parle.

T'inquiètes, quelle que soit la solution, quand on aura compris, ça sera

[Smint]

Salut tous.... Je vous reviens après une installation calamiteuse de LiveBox qui m'a privé de connexion pas mal de temps hier....

Papy turbo, j'essaie de satisfaire à ta demande de précisions.....

- toute une table, (laquelle ? comment elle s'appelle ? quel champ ? date de quoi ?)
- seulement ceux qui sont sélectionnés dans le formulaire ?

Il s'agit d'une requête de sélection. J'obtiens donc une feuille de données qui comprend, entre autres, un champ nommé "Envoi", formaté en date abrégée....
Je désire saisir la même date pour le champ "Envoi" et ce sur tous les enregistrements que la requête a sélectionné.

J'espère être clair... pô si simple .......

Merci, en espérant que vous auriez une soluce....
Ca pourrait se faire avec une requête de mise à jour mais j'ai de bonnes raisons de vouloir faire autrement....

La sélection se fait sur 5 critères variables, avec des valeurs mini et maxi. Elle est exécutée plusieurs fois, en faisant varier les critères, pour décider d'une liste d'envois à effectuer. Les données sélectionnées servent à l'édition d'étiquettes. La mise à jour du champ "Envoi" que je cherche à faire me permettra de mémoriser quand l'envoi a été effectué.

1°) Ca implique la resaisie des 10 minis et maxis des critères de sélection. Une erreur de saisie à ce niveau et je suis planté gravement....
2°) Ma chérie est susceptible de me donner parfois un coup de main et d'utiliser ma base. Je souhaite éviter qu'elle touche aux objets, elle ne connait rien à Access.....

Ce que j'aurais voulu:

Quelques chose qui ressemble à ce qui est possible sous Excel, en terme de recopie vers le bas....

Suite à différents essais en fonctions de ces fameux critères, j'ai donc une feuille de données comportant les champs renseignés de ce qu'il me faut pour mon publipostage et ce fameux champ "Envoi", vide sur tous les enregistrements.....
Je saisie la date dans le champ "Envoi" de l'enregistrement 1 et (c'est là que j'ai besoin de vos lumières) je le recopie jusqu'au dernier enregistrement de la requête... (comme par exemple avec la "poignée" sous Excel...)

Merci de me lire.... espérant que vous auriez une soluce...
Bonne journée...

[cafeine]

Dans access 97 et 2000, il n'y a pas de recopie vers le bas.

Cela doit se traduire par une requête mise à jour, le tout est de savoir sur quels critères se baser pour faire cette mise à jour.

Le plus simple serait peut être de transformer ta requête sélection en requête création de table, et d'opérer sur cette nouvelle table.

[Alexandre Sahli]

si j'ai bien compris tu as un formulaire pour saisir la date d'envoi.
Personellement je travaillerais de la façon suivante:

je placerais une zone de texte pour insérer la date que tu désires
puis j'aurais un bouton (mettre la date ) et la tu fais le code suivant

Code :

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

1
2
3
4
5
6
 
dim strSql as string
strsql = "INSERT INTO matable ( champdate ) VALUES ("& format(me![mazonedetextedate],"mm/dd/yyyy") &") WHERE (critères identiques à ceux du formulaire);
docmd.setwarnings false
docmd.runsql strsql
docmd.setwarnings true

de cette façon ta date sera mise à la sélection d'enregistrement que tu as dans ton formulaire

A+

[Smint]

Salut Alexandre,

si j'ai bien compris tu as un formulaire pour saisir la date d'envoi.

non..... L'exécution de la requête me donne une feuille de donnée... Pourtant, c'est bien une solution de ce type qui me ferait plaisir...:

Je saisie la date dans le champ "Envoi" de l'enregistrement 1 et (c'est là que j'ai besoin de vos lumières) je le recopie jusqu'au dernier enregistrement de la requête...

Salut Céféine,

Le plus simple serait peut être de transformer ta requête sélection en requête création de table, et d'opérer sur cette nouvelle table.

Bâ non.... même problème qu'avec une requête de mise à jour:

La sélection se fait sur 5 critères variables, avec des valeurs mini et maxi. Elle est exécutée plusieurs fois, en faisant varier les critères, pour décider d'une liste d'envois à effectuer. Les données sélectionnées servent à l'édition d'étiquettes. La mise à jour du champ "Envoi" que je cherche à faire me permettra de mémoriser quand l'envoi a été effectué.

1°) Ca implique la resaisie des 10 minis et maxis des critères de sélection. Une erreur de saisie à ce niveau et je suis planté gravement....

[Alexandre Sahli]

même si c'est une feuille de donnée
tu peux faire un formulaire avec comme base la requête que tu exécutes et dans l'entête de ton formulaire tu mets ta zone de texte et le bouton comme je te l'ai expliqué et le tour est joué

[Papy Turbo]

D'accord avec Alexandre : pour exécuter quoi que ce soit, il te faut un formulaire, sinon tu ne pourras exécuter aucun code.

Donc, utiliser l'assistant pour créer un formulaire en mode "feuille de données".

Ensuite, même si tu ne veux pas resaisir ou retrouver les critères de ton formulaire, rien de + facile qu'une fonction VBA, avec DAO, qui recopie ta valeur dans tout le recordset du formulaire en question.
C'est à dire, sur tous les enregistrements que tu as aujourd'hui dans ta feuille de données.

On va commencer simple, en disant que
- lorsque tu changes une date quelconque dans le champ Envoi (que ce soit sur la 1ère ligne, sur la dernière, ou peu importe),
- tu recopies cette date partout.
(comme la plupart des logiciels comptables, pour toutes les lignes d'une même pièce )

Donc, dans ton formulaire, tu crées un évènement _AfterUpdate (après mise à jour) pour le contrôle Envoi, et tu rajoutes le code :

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
Private Sub Envoi_AfterUpdate()
    'Sauvegarder l'enregistrement en cours, 
    '    sinon conflit d'écriture pendant la boucle ci-dessous
    Docmd.Runcommand acCmdSaveRecord
    'Utiliser le CLONE du recordset, pour ne PAS déplacer 
    '    l'enregistrement en cours sur le formulaire
    With Me.RecordsetClone
        .MoveFirst
        Do while Not .Eof
            .Edit
            'copie la valeur du contrôle dans le champ de chaque ligne
            ![Envoi] = Me.Envoi 
            .Update
            .MoveNext
         Loop
    End With
End Sub

Tu utilises ainsi tous les enregistrements qui sont présents et affichés dans le formulaire.
Attention, si tu utilises un filtre (n'importe quel bouton de filtre, sur la barre d'outils)... seuls les enregistrements affichés au moment se la saisie seront concernés.

Attention, ce code est tapé 'à la volée', sans être testé. À toi de le tester...

P.S. dis à ta copine de venir sur le forum. Dans un mois, elle aura transformé tout ça en une belle appli professionnelle... 8)

[Alexandre Sahli]

Papy turbo, merci bien là tu m'épate, j'apprends vraiment quelque chose

super !!!!

A+

[Smint]

Ok.... Merci Papy Turbo....

Comme je n'ai pas terminé la réinstallation de mon système, je laisse ça en standbye qq heures... puis, j'essaie et reviens faire le point....

P.S. dis à ta copine de venir sur le forum. Dans un mois, elle aura transformé tout ça en une belle appli professionnelle...

Elle ne partage pas, mais pas du tout, la passion que nous pouvons avoir pour l'informatique....

Bonne journée à tous!

[Smint]

Salut à tous... J'espère que vous avez passé un bon week-end... Excellente semaine à vous!!

Papy Turbo: Excellent cette manip... J'ai mis en oeuvre ce matin et ça fonctionne impeccablement..... J'ai d'ailleurs répercuté ce code sur d'autres champs à mettre à jour, sur le même formulaire, sans souci...

Un grand, très grand merci à toi.....

En revanche, le code se plante dans un autre formulaire, dans des circonstances un peu différentes puisque la mise à jour déclenche, via la jointure, la mise à jour d'un champ numérique auto qui est clef primaire dans une table liée.... J'essaie de t'expliquer ça clairement....

Deux tables (Collaborateurs" et "Actions') liées par une relation de 1 à plusieurs de type 2 et le champ PubCom (Vrai ou Faux), qu'il s'agit de mettre à jour, via ton code.... (Null avant la mise à jour)


Voilà la situation après lancement du formulaire:


Je vais donc cocher une des coches de "PubCom": L'ensemble des enregistrement devrait passer sur vrai, et, en fonction de la jointure, les numéros de "NumCol"devraient se recopier en "NumAct"....





Je ferme la fenêtre VBA:


Et là, si je décoche et recoche au même endroit, le champ se met à jour dans tous les enregistrements comme prévu....


Pour conclure ce roman photo... Si je fais un copier/coller de la colonne "NumCol" sur la colonne "NumAct", le code fonctionne parfaitement comme dans les autres formulaires.... Apparemment, c'est la mise à jour du champ "NumAct" qui lui fait claquer des dents...

Voilà, merci encore... si tu vois ce qui déconne, ça serait sympa de modifier, histoire d'avoir qq chose de nickel.. sinon, je ferais le copier/coller "NumCol"/"NumAct" ou passerai faire un tour chez débogueur...

[Smint]

Salut le forum....

Z'auriez pas vu Papy Turbo?

[Papy Turbo]

1- fais une recherche sur le forum : "Un autre utilisateur..." - j'ai répondu sur ce sujet la semaine dernière (le sujet est marqué [FAQ]). À tout hasard, cherche aussi "Conflit d'écriture" : y en a 2 ou 3.

2- relis le code, y compris les commentaires, en particulier le premier :
- la routine commence par un SaveRecord, précisément pour éviter ce conflit d'écriture, à savoir toi (en cliquant dans le formulaire) et toi (en passant par du code VBA), tu essayes deux fois de modifier le même enregistrement.
- du fait qu'on a fait un SaveRecord, ça ne devrait pas se produire.
- en pas à pas, il faut que tu testes la valeur de Me.Dirty pour savoir si l'enregistrement du formulaire s'est bien fait ? Si échec, Me.Dirty sera True après le SaveRecord. Pourquoi il est pas False (donc propre, enregistré) ???
- je ne comprends rien à tes histoires de copie de NumCol dans NumAct ???

Sur le fond, je suis assez choqué de la manière dont tu traites tes données :
+ copie vers le bas,
+ copie d'une colonne dans l'autre,
On n'est pas dans Excel et il y a d'autres méthodes qui correspondent à la gestion d'une base de données. Il faut que tu t'y mettes (revoir les tutoriels de base).
Ce qui me choque carrément :
+ le champ Collaborateurs!NumCol est lié par intégrité au champ Actions!NumAct.
Tu dois corriger cela en renommant l'un des deux, probablement Actions!NumAct doit devenir Actions!NumCol : si un Collaborateur a plusieurs actions, il faut trouver le Numéro du Collaborateur dans chaque action de ce Collaborateur.
Sinon, toi (dans 6 mois) et n'importe qui qui intervient là dessus serez tous paumés...
Regarde ton code, je n'ai pas compris cette "copie de NumCol dans NumAct" non plus.
Ce n'est pas clair, et ça ne devrait jamais se faire par copie...
Je soupçonne que c'est là que ça plante, mais je ne sais pas ce que tu veux faire ?

Attention, si tu continues avec ce type d'approche, tu vas tout le temps avoir des conflits.
Stop, et analyse de fond indispensables avant qu'il ne soit trop tard.

Si tu nous expliques le fond de ce que tu veux faire, on peut peut être revoir l'analyse et la méthode pour gérer les Collaborateurs, leurs Actions... N'hésite pas à poser tes questions.

Bon courage.

[Smint]

Salut Papy Turbo..... Content de te voir passer par là...

Je le constate encore une fois, que ce soit le dépanneur ou le dépanné, il est vraiment difficile de se comprendre via du simple texte, sans être ensemble sur le même PC... Je l'ai beaucoup expérimenté, dépannant moi aussi, mais sur un forum Windows, Internet, Sécurité...

Tu l'auras peut-être compris, je ne suis absolument pas un développeur. Mon métier, c'est la négociation, le marketing, l'action commerciale... Ma connaissance des BdD se limitent à une formation à Dbase3 datant de 86, à Access, de 40 heures, il y a deux ans... Tout ce que je sais de la création d'un évènement, de l'insertion d'un code VBA, je l'ai appris sur la toile, dont beaucoup avec vous....

Sur le fond, je suis assez choqué de la manière dont tu traites tes données :
+ copie vers le bas,
+ copie d'une colonne dans l'autre,

C'est bien parce que je savais que ce n'était pas terrible que j'ai voulu faire autrement. J'aurais su aussi faire avec des requêtes de mise à jour, mais je ne le souhaitais pas pour des raisons que j'explique plus haut...

Ce qui me choque carrément :
+ le champ Collaborateurs!NumCol est lié par intégrité au champ Actions!NumAct.
Tu dois corriger cela en renommant l'un des deux, probablement Actions!NumAct doit devenir Actions!NumCol : si un Collaborateur a plusieurs actions, il faut trouver le Numéro du Collaborateur dans chaque action de ce Collaborateur.

Là, c'est moi qui ne te comprends pas. A ce que j'ai compris, la liaison entre deux tables doit se faire par des champs de même type, mais pas forcément de même nom, non?

Quand plusieurs actions ont été menées vers un collaborateur et dûment enregistrées, classiquement, via un formulaire, bien sur que, pour chaque action, est enregistré, en Actions!NumAct le numéro du collaborateur Collaborateur!NumCol....

Dans la mesure où je fais une mise à jour, grace à ton code, dans une requête où qui rassemble des collaborateurs et des actions déjà crées, donc Action!NumAct<>Null, tout se passe parfaitement!

Ca coince simplement quand la mise à jour doit déclencher la création d'un nouvel enregistrement dans la table Action, comme ici:


Quand il s'agit de la mise à jour d'un fiche, il y a un numéro dans Action!NumAct et la coche de Action!PubCom n'est pas grisé.. et tout se passe bien comme je te l'ai dit plus haut...
Ici, le problème, c'est qu'en cochant les contrôles PubCom, on va créer autant d'enregistrements dans la table action, et c'est là que ça coince... cad que le débogeur s'ouvre et il suffit de le fermer pour que le code s'exécute sans problème, mettant à jour toutes les coches de Action!PubCom, et affectant les numéros de collaborateurs correspondant dans Action!NumAct....

Pour info, la structure de la base:

- je ne comprends rien à tes histoires de copie de NumCol dans NumAct ???

Je ne tiens pas à le faire, c'est simplement que j'ai vérifié que si, via cette copie, on crée les enregistrement dans la table Action, ton code fonctionne parfaitement, dès que l'on coche un des Action!PubCom, la mise à jour s'effectue sur tous les enregistrements...

Voilà.... es-tu toujours persuadé que la structure de la base est à revoir totalement?

1 entreprises fait travailler des collaborateurs.... Vers chaque collaborateurs, nous pouvons mener plusieurs ou aucune action... Chaque collaborateur peur avoir plusieurs ou aucun projets à mener, peut avoir, éventuellement un(e) collaborateur(trice)...

Les relations de la base:


Et encore, un immense merci à toi et à ceux qui m'ont apporté leur savoir sur d'autres fils...

[Papy Turbo]

(sifflet admiratif) bravo pour des explications très claires et documentées.
C'est un plaisir de répondre

Je comprends mieux, et la structure des tables est claire (et rien à reprendre là dessus )
Les tables sont même disposées dans l'ordre, de gauche à droite : parfait (dixit le pinailleur de service).

Donc,

Là, c'est moi qui ne te comprends pas. A ce que j'ai compris, la liaison entre deux tables doit se faire par des champs de même type, mais pas forcément de même nom, non?

Si. Enfin, ce n'est pas obligé, bien sûr, mais
- quand je lis Actions!NumAct, je m'attends à trouver ... le numéro d'Action, c. à d. la clé de l'action, pas du collaborateur.
Le nom du champ décrit ce qu'il contient.
C'est ça qui m'a choqué.
J'ai toujours vu les archis de base de données garder le même nom de champ dans toutes les tables, pour
- que ce soit clairement évident : la clé du collaborateur dans chaque table, y compris NumAss (qui en plus, en anglais, sonne pas terrible, mais je rigole, laisse tomber) qui doit aussi devenir NumCol,
- qu'Access puisse automatiquement te relier les tables dans les requêtes (il se base sur le nom - lui aussi s'attend à ça).

En passant, j'ai vu des bases complexes où chaque instance du NumCol portait un n° différent :
- NumCol dans Collaborateur,
- NumCol1 dans Actions,
- NumCol2 dans Assistant...
C'est très très chiant (scuse le terme technique) à manipuler : tu ne sais jamais le nom du champ, faut tout le temps vérifier...
Donc, à éviter.
Y a aussi plus simple, parce que prévisible :
- ColNumCol dans Collaborateur,
- ActNumCol dans Actions,
- AssNumCol dans Assistant...
Mais bon, quel intérêt ?


----
Je comprends maitenant que tu veux ajouter des Actions pour une certaine sélection de collaborateurs.
OK.
Et ça marche, en copiant les NumCol dedans.
Mais c'est pas net.
>> Pour chaque collaborateur, y a des actions.
Ta requête (source du formulaire) inclut :
- un collaborateur + une action (à créer).
C'est pas logique de BDD, ça. la logique voudrait :
- pour chaque collaborateur (= 1 enregistrement sur formulaire principal),
- 0, ou 1 , ou des actions dans le sous-formulaire Actions
- champs père/Champs fils du sous formulaire Actions = NumCol.
Les formulaires et sous formulaires sont (devraient être) le reflet de la structure des tables.
Donc, j'aurais aussi un sous formulaire Assistants (du collaborateur) à côté du sous formulaire Actions.

J'aimerais bien voir le code de la requête en question ?!?

Et, quand tu crées toute une série d'actions (envoi de plaquettes ?), il doit y avoir d'autres champs à renseigner :
- date d'action = date du jour ?
- type d'action = "envoi de plaquette" ?
- autre ?

Donc, définitivement, je préfèrerais un formulaire contenant un bouton qui déclenche clairement ce code :
1- cocher tous les PubCom (en évitant tout conflit d'enregistrement )
2- créer une action pour chaque collaborateur affiché dans le form., avec chaque valeur dans le champ approprié.

Ce qui consisterait, au plus simple, à
- créer un formulaire principal, vide,
- mettre ton formulaire actuel "Plaquettes Commerciaux à Envoyer" dessus, en tant que sous formulaire - Nom du contrôle Sous formulaire = "SsFormPlaquettes" (par exemple)
- dans l'en-tête du form. principal, tu vas pouvoir mettre plein de choses, notamment pour sélectionner les bons collaborateurs sur divers critères, mais, pour aujourd'hui, on va se contenter d'un bouton 'Envoyer les plaquettes' - Nom du bouton = "btnEnvoi"
- le code précédent est à remplacer par un évènement clic du bouton "btnEnvoi", sachant qu'il n'y a plus besoin de sauvegarder l'enregistrement, parce qu'il n'y a plus de risque de conflit d'écriture :
STOP. Je viens de voir plus haut que ton PubCom est en fait dans la table Actions ! C'est ça qui cafouille tout : dès que tu le modifies, tu crées l'enregistrement dans la table Action !!! Et quand tu copies les NumCol...
Aïe, aïe, aïe les conflits d'écriture.
Donc, ça donne, toujours avec
- un bouton séparé, au dessus,
- un sous formulaire non modifiable (pour éviter ce genre de mélanges) (propriété Modif autorisée = Non)

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
Private Sub btnEnvoi_Click()
Dim db As DAO.Database
Dim rs as DAO.Recordset
Dim CurrentNumCol as long
 
    Set db = CurrentDb
    Set rs = db.OpenRecordset("Actions")
    'Utiliser le CLONE du recordset, pour ne PAS déplacer 
    '    l'enregistrement en cours sur le formulaire 
    With SsFormPlaquettes.Form.RecordsetClone 
        .MoveFirst 
        Do while Not .Eof 
            CurrentNumCol = !NumCol
            'Ajout d'une action correspondante :
            With rs
                .AddNew
                'copie du NumCol du sous formulaire dans la nouvelle Action
                !NumCol = CurrentNumCol
                !PubCom = True
                !DateAction = Now
                !TypeAction = "Envoi de plaquette" 'par exemple ??
                'autres champs ...
                .Update
            End With
            .MoveNext ' collaborateur suivant
         Loop 
    End With 
    'réaffiche les modifications ci-dessus
    SsFormPlaquettes.requery
End Sub

Là, tu contrôles réellement ce qu'il se passe, ligne par ligne et champ par champ...

Honnêtement, après avoir relu tout ça, je recommencerais avec une structure de formulaires claire.
Je pense que toute ton application peut tenir sur
- un seul formulaire principal, contenant dans l'en tête tous les champs nécessaires pour faire tes sélections de collaborateurs.
Voir le tuto de Cafeine + le nouveau tuto de ?? (ça m'échappe, j'espère que je serai pardonné), sur le même sujet : faire des sélections.
Seule différence : au lieu d'appliquer tes sélections à une liste, tu vas créer un filtre pour le sous formulaire Collaborateurs.
- un sous formulaire Collaborateurs, en mode feuille de données (pour les sélections, recherches...) et/ou mode formulaire (pour la saisie...)
- sur le sous form. Collaborateurs, 2 sous formulaires :
- un pour les Actions,
- un pour les Assistants.

Retour dans l'en tête du formulaire principal (ou dans un menu sur mesure, ou...) : une série de boutons qui permettent
- d'envoyer une plaquette à tous les collaborateurs sélectionnés à l'écran,
- etc. toutes sortes d'actions possibles...

Voili voilou.
Ton appli toute entière (à peu de choses près) doit tenir sur un seul formulaire.
Et c'est moins compliqué que ce que tu fais. (enfin, mon impression)

[Smint]

sifflet admiratif) bravo pour des explications très claires et documentées.

Ca me parait la moindre des choses, au vu de la patience que vous montrez tous et de la qualité des réponses obtenus... J'ai bien avancé et bien appris en quelques semaines, grace à ce forum....

Si. Enfin, ce n'est pas obligé, bien sûr, mais
- quand je lis Actions!NumAct, je m'attends à trouver ...

...... Y a aussi plus simple, parce que prévisible :
- ColNumCol dans Collaborateur,
- ActNumCol dans Actions,
- AssNumCol dans Assistant...
Mais bon, quel intérêt ?

Bon, je n'avais pas compris que le nom pouvait être le même et que c'était même souhaitable... Je le saurais à l'avenir.... Dans ma tête, c'est aussi plus simple ainsi, selon la terminaison du champ, je sais de quelle table il est...
Si ça ne pose pas de terme majeur, je voudrais laisser dans l'état... Si je change le nom dans les tables, c'est mes requêtes, mes formulaires qui vont se vautrer et ça me gave de tout refaire.... Faudrait aussi que je revienne à passer plus de temps sur mon métier propre, sinon, je ne vais pas tarder à ne plus manger... ... donc, sauf contre-indication majeure....

Je comprends maitenant que tu veux ajouter des Actions pour une certaine sélection de collaborateurs.
OK.
Et ça marche, en copiant les NumCol dedans.
Mais c'est pas net.
>> Pour chaque collaborateur, y a des actions.

Nan, justement.... c'est selon.....

Les formulaires et sous formulaires sont (devraient être) le reflet de la structure des tables.
Donc, j'aurais aussi un sous formulaire Assistants (du collaborateur) à côté du sous formulaire Actions.

C'est le cas... ;-)

Et, quand tu crées toute une série d'actions (envoi de plaquettes ?), il doit y avoir d'autres champs à renseigner :
- date d'action = date du jour ?
- type d'action = "envoi de plaquette" ?
- autre ?

Exact.....

Quand je crée une action au coup par coup, je passe par le formulaire et pas de problème (si ce n'est ça: http://www.developpez.net/forums/viewtopic.php?t=402283 ;-) ) ... En revanche, en cas d'actions groupées, c'est plusieurs dizaines de contrôles à modifier, d'où ma demande.....

Bref.... La solution alternative que tu me proposes, cher Papy Turbo, est certe surement beaucoup plus professionnelle que le petit code inséré sur l'évènement update, comme nous l'avons fait avant... Mais, franchement, ta solution précédente fonctionne parfaitement.... sauf, effectivement, quand je veux cocher des Action!PubCom, sur des enregistrements encore non créés....... Et encore.... Le débogueur ouvre une fenêtre, il suffit de la fermer et de refaire la manip et tout fonctionne.... Franchement, je n'ai ni le courage, ni le temps de tout refaire.....

Donc, à moins que tu ne vois une modification du code que nous utilisons actuellement, histoire de claquer son baigneur au débogueur, on va en rester là.... Si il te manque encore des infos, dis-le-moi...

PS: Effectivement, NumAss, en British, ça sonne bizarre....

.............. sans oublier un énorme merci!!