Gérer les sous feuilles de données

badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 - 10 oct. 2023 à 06:55
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 - 22 déc. 2023 à 15:11

Bonjour,

j'ai de nouveau besoin d'aide....

Actuellement ma table « T_residence » me propose en sous feuille de données, les différents types de financement, qui me donnent les différentes activités de chaque type de financement, etc…

J’aimerais aussi, que ma table « T_residence » me propose en sous feuilles de données, les différents logements(tels logements appartiennent à telle résidence).

Quand je créé une relation entre ma table « T_logements » et « T_residence »,en retournant sur ma table « T_residence », et en cliquant sur le petit « + », j’ai une fenêtre qui s’ouvre qui me demande de choisir la sous feuille de données que je veux.

Mais j’aimerais avoir les deux .

Est-ce que la piste à explorer serait celle de la création d’une table de liens ?

Si oui, ce qu’on appelle des clés étrangères, doivent elles formatées en « numeroauto » ou faut il leur attribuer un autre type de format de données ?

33 réponses

yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
12 oct. 2023 à 15:33

Réponse au #36:

Même si la date de naissance n'est requise que pour certaines catégories de personne, je la mettrais dans la table personnes.

Quand un nouveau résident arrive, il faut en effet d'abord créer un enregistrement dans la table personne, puis un enregistrement dans la table "résidents".

Sur le champs "id_personne" de la table residents, la liste déroulante va proposer toutes les personnes sélectionnées par une requête, rien n'empêche d'utiliser la catégorie et d'autres choses dans cette requête.  Je ne suis pas convaincu qu'une liste déroulante dans une feuille de données soit le bon choix ergonomique.  La table residents, c'est plutôt une table qui enregistre les entrées des personnes dans la résidence, non?

Des coordonnées, cela n'a pas sa place dans la table personnes?

Les relations méritent peut-être une table relations, ce qui permettrait d'avoir une personne en relation avec plusieurs résidents.

Plusieurs tables peuvent, le cas échéant, utiliser "id_personne" comme pour la table résidents.  Par exemple, si tu avais une table "engagements", qui enregistre les engagements de travailleurs.

Je pense qu'il est souvent bien qu'une table corresponde à un "objet", tel qu'une personne, ou à une action, telle que l'inscription à une animation ou à l'entrée dans une résidence.  Je ne suis pas expert dans le domaine de la modélisation des données.

1
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
Modifié le 12 oct. 2023 à 16:41

Réponse au #42:

1.- " Je ne suis pas convaincu qu'une liste déroulante dans une feuille de données soit le bon choix ergonomique. 

- La table residents, c'est plutôt une table qui enregistre les entrées des personnes dans la résidence, non?"

--> - oui, en effet, c'est pour enregistrer l'entrée d'un résident, mais pour moi c'était aussi pour recenser toutes les informations relatives aux résidents. Avec l'idée de pouvoir générer une "fiche information du résident", (logement, âge, famille (proches du résident), aides financières perçues,etc...)

- Mais pour pouvoir faire une requête, il faut bien activer une liste de choix, en choisissant "liste déroulante" ou "zone de liste" dans la propriété contenu de l'affichage (dans les propriétés de paramétrage d'un champs), non? Je vais forcément avoir une liste? 

2. "Des coordonnées, cela n'a pas sa place dans la table personnes?"

--> oui c'est vrai, pourquoi pas. Dans ce cas l'id_personne d'une table doit contenir "civilités, nom, prenom, date de naissance, coordonnées"?

3."Les relations méritent peut-être une table relations, ce qui permettrait d'avoir une personne en relation avec plusieurs résidents."

--> c'est peut être une question bête, mais ici, une personne ne serait pas en relation avec plusieurs résidents. c'est l'inverse, un resident peut être en relation avec différentes personnes. L'idée pour moi, c'est de rencenser, si le résident a eu un ami, un frère, un fils qu'a participé à une activité et/ou qui peut être contacter si le résident a un problème. Est ce qu'ici aussi une table relation des relations est pertinente? pour moi une relation, est à la fois un attribut de la table résident et à la fois une personne qui relève de la catégorie proche que je cherche à suivre dans la participation aux activités.

4.. Je pense qu'il est souvent bien qu'une table corresponde à un "objet", tel qu'une personne, ou à une action, telle que l'inscription à une animation ou à l'entrée dans une résidence. 

--> donc par exemple, si je souhaite recenser la perception de l'allocation logement des résidents. Je dois faire une table "allocation logement". Je pensais que c'était un attribut du résident, avec un oui, non. Ce qui permettait d'extraire qui la perçoi

5. Je ne suis pas expert dans le domaine de la modélisation des données.

--> tu me parais quand même très très bon!

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
12 oct. 2023 à 16:42

réponse au #43:

1) plutôt que de définir les possibilités de choix dans le champ de la table, il est parfois préférable de faire comme tu as fait pour les inscriptions de résidents aux animations, en définissant les possibilités de choix dans un formulaire.

2) "l'id_personne d'une table doit contenir ...": tu fais référence à l'info qu'on montre dans la liste pour choisir une personne à partir d'une autre table?  C'est toi qui décides quoi y montrer, le but est de permettre de distinguer les personnes pour choisir la bonne.  Techniquement, dans l'autre table, id_personne, c'est juste un nombre, égal à la valeur du champ "autonumber" de la table personnes.

3) si la perception de l'allocation logement, c'est une action à enregistrer, avec, par exemple, une date et un montant, alors cela justifie une table.

-) Un résident peut-il déménager?  Les dates d'entrée et de sortie sont-elles destinées à suivre l'historique de cela?

Est-il nécessaire de garder l'historique d'autres élements?  Cela crée parfois des besoins en terme de structure des données.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
12 oct. 2023 à 18:28

1) ok compris

2) Non je faisais référence au champs d'une table. "

  • une table personnes avec (civilite, nom, prenom, date de naissance, catégorie).  la catégorie : résident, exterieur, proche, autre.  Pas besoin de préciser si résident 1 ou 2, c'est déjà enregistré dans la table residents 
  • dans la table residents, remplacer les champs (civilite, nom, prenom, date de naissance) par un champ id_personne

ce que je voulais dire, c'est que je fais pareil mais en intégrant coordonnées

D'ailleurs, comment on gère l'affichage, par exemple dans le sous formulaire du formulaire ajout? Une fois qu'on ajoute un participant, on ne voit que le prenom. au mieux j'aimerais pouvoir afficher nom + prenom, sinon au moins le nom.

3) ok, compris

4) oui un résident peut déménager, c'est assez rare mais ça arrive. Les dates d'entrée et de séjour me permettent de tenir à jour une sorte de registre des entrées et sorties mais aussi de faire des stats (durée de séjour).

"Est-il nécessaire de garder l'historique d'autres élements?  Cela crée parfois des besoins en terme de structure des données."

je me dis toujours que c'est bien d'avoir toutes les infos ^^

Je n'arrive pas encore à distinguer ce qu'elle info, est superficielle... Je crois que tout ce que j'ai renseigné à un rôle. A quoi tu penserais par exemple?

Merci, (je le dis pas à chaque fois, et quand je le dis, j'ai l'impression de fayoter au bout d'un moment). mais c'est très sincère.

Merci beaucoup pour tout le temps que tu consacres à m'aider et à répondre à mes questions de noob.

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
13 oct. 2023 à 08:01

2) oui, ajouter coordonnées dans la table personnes.

Pour gérer l'affichage de la personne dans la table participants, tu peux changer la requête associée au champ dans la table participants en ceci, par exemple:

SELECT T_residents.id_resident, [T_residents].[prenom] & " " & [T_residents].[nom] AS Expr1
FROM T_residents
ORDER BY T_residents.[nom], T_residents.[prenom];

4) pas de suggestion, c'était une invitation à ce que tu y sois attentif

-) avec plaisir

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
13 oct. 2023 à 10:26

Je suis complètement perdu...

Avec cette nouvelle table personne, j'ai dû refaire mes formulaires d'ajout et de consultation.

Du coup je ne sais pas du tout comment adapter mes requêtes: residents_presents, r_inscrits et r_noninscrits.

Par ailleurs, j'ai ajouté la zone de texte "filtre" et je ne comprends pas comment m'en servir. 

Est ce que tu peux stp intervenir sur mon fichier parce que là je fais n'importe quoi?

Mon fichier : https://www.cjoint.com/c/MJniw5JhdlE

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
10 oct. 2023 à 10:33

bonjour,

Je découvre le concept de sous feuille de données.  J'ai un peu regardé, et je ne suis pas convaincu que c'est très utile dans ton contexte.  C'est plutôt destiné au gestionnaire de la base de données, ce n'est pas destiné à remplacer des formulaires pour les utilisateurs de la base.

Une feuille de données ne peut avoir plusieurs sous feuilles de données.

Qu'essaies-tu de réaliser?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
10 oct. 2023 à 10:57

j'essaie de récupérer les informations par résidence : 

- d'une part, ce qui concerne les animations : ça c'est bon

- d'autre part, ce qui concerne l'occupation des logements : residence 1, logement X, occupé par ce resident, puis ce resident, etc...

Aussi, je voudrais pouvoir rajouter une autre fonction sur le formulaire d'ajout.

je voudrais que ma liste de participants proposées se mettent à jour en fonction du choix d'une résidence ou d'une autre.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
Modifié le 10 oct. 2023 à 11:58

là je suis en train d'essayer de créer une requête des résidents présents de la résidence Le Titien. Mais je n'y parviens pas. 

https://www.cjoint.com/c/MJkj5VA3e0E

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
10 oct. 2023 à 12:03

La récupération d'information se fait souvent via des requêtes, et l'affichage via des rapports.
Pour tenir compte de la résidence dans la fonction d'ajout, je ferais ainsi:

  • ajouter la résidence de chaque résident dans les requêtes utilisées pour construire la liste
  • créer une nouvelle requête qui filtre les non inscrits en fonction de la résidence où se passe l'animation du formulaire
  • utiliser cette nouvelle requête pour peupler la liste des participants proposés
0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
10 oct. 2023 à 12:13

je vais tester. Merci

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
10 oct. 2023 à 12:23

Dans la table logements, le champ Residence doit être numérique, pour pouvoir être lié au champ ID de la table residence.

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
11 oct. 2023 à 07:15

Une méthode possible pour que la zone de liste puisse s'actualiser en fonction d'un clic sur un des boutons de la catégorie des participants:

  • ajouter une zone de texte dans le formulaire, disons "filtre".  Cette zone peut être invisible et/ou non modifiable.
  • utiliser ce filtre dans la requête qui construit la liste des candidats participants
  • dans la macro associée au bouton, utiliser "définir propriété" pour changer la valeur du filtre, et puis "exécuter la requête" pour rafraichir la liste
0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
Modifié le 12 oct. 2023 à 13:01

En gros, les relations ont deux rôles:

  • quand on crée quelque chose (requête, formulaire ou rapport) qui combine les données de plusieurs tables, il est nécessaire de spécifier comment cette combinaison doit se faire.  Les relations permettent de ne pas devoir répéter cette spécification pour chaque objet créé.
  • Il est possible d'associer des contraintes à une relation.  Par exemple, imposer qu'un proche soit lié à un résident.  La contrainte empêche, par exemple, de supprimer un résident ayant un proche, ou de créer un proche sans résident existant lié.

Comme tu n'as pas créé de contrainte, tu peux supprimer les relations, le seul effet sera d'un peu te compliquer la vie ensuite.

J'arrête de faire des suggestions non sollicitées sur la structure de tes tables, comme tu n'en tiens pas compte.  Ce qui est bien ton droit et que j'accepte totalement.

1
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
12 oct. 2023 à 13:40

Si on laisse les contraintes de côté, les relations n'existent et n'ont d'effet que dans les requêtes.  Tu as bien compris.  Tu peux aussi supprimer une relation proposée, juste pour une requête.  Ou modifier le type de jointure d'une relation, pour une requête.

1
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
12 oct. 2023 à 13:52

Pour empêcher de créer une participation sans participant, il faut jouer sur la définition du champ id_participant de la table T_participations: mettre "Null interdit" à "oui".

1
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
12 oct. 2023 à 14:10

Nous n'avons pas encore utilisé de contrainte.

Les jointures sont présentes presque partout.  Les jointures simples peuvent être visualisées et éditées en cliquant avec le bouton de droite sur une relation.

C'est un concept crucial dans les bases de données relationnelles.  

1
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
12 oct. 2023 à 15:40

réponse au #40
La liste peut proposer toutes les personnes vivantes de la catégorie "résident" qui ne sont pour le moment dans aucune résidence.

1
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
14 oct. 2023 à 08:07

réponse au #71

Je n'ai pas encore testé la requête, je ne sais pas si j'ai une base qui lui convient. 

Je suppose que tu as une partie des requêtes qui donnent "jointures ambigues", l'autre partie qui donne un résultat vide. 

Afin d'analyser si le souci vient des jointures ou bien des conditions (filtres), teste sans la clause WHERE de la requête (sans aucune des conditions).  Cela doit te donner toutes les personnes, avec les détails voulus.  Ensuite, tu ajoutes les conditions.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
14 oct. 2023 à 08:46

Oui c'est ça : 10 requêtes me donnent un résultats vide et 17 avec le message d'erreur.

je vais essayer sans les conditions.

si besoin, ma base actuelle : https://www.cjoint.com/c/MJogS6NhxlE

0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
14 oct. 2023 à 08:49

Tu comprends la suggestion "créez une requête distincte qui execute la première jointure, puis inserer cette requete dans votre instruction"?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
14 oct. 2023 à 09:17

dans l'idée oui... mais dans la réalisation non 

quand j'enlève toutes les conditions, j'ai la même liste de participants proposée (uniquement les résidents, les deux résidences confondues) peu importe la catégorie du participant.

Quand j'ajoute les conditions : 

SELECT T_personne.id_personne, T_personne.nom, T_personne.prenom, T_personne.categorie_personne, [Forms]![F_ajouter_suivi_activites]![endroit] AS Expr1, T_logements.id_logement
FROM T_personne LEFT JOIN ((T_logements LEFT JOIN T_residences ON T_logements.id_residence = T_residences.id_residence) RIGHT JOIN T_residents ON T_logements.id_logement = T_residents.id_logement) ON T_personne.id_personne = T_residents.id_personne
WHERE (((T_personne.categorie_personne)=[Formulaires]![F_ajouter_suivi_activites]![filtre]) AND (([Forms]![F_ajouter_suivi_activites]![endroit])="I") AND ((T_logements.id_logement)=[Forms]![F_ajouter_suivi_activites]![F_ch_id_residence])) OR (((T_personne.categorie_personne)=[Formulaires]![F_ajouter_suivi_activites]![filtre]) AND (([Forms]![F_ajouter_suivi_activites]![endroit])="A") AND ((T_logements.id_logement)<>[Forms]![F_ajouter_suivi_activites]![F_ch_id_residence])) OR (((T_personne.categorie_personne)=[Formulaires]![F_ajouter_suivi_activites]![filtre]) AND (([Forms]![F_ajouter_suivi_activites]![endroit])="T"));

Il y a une combinaison de jointures qui me donnent à peu près ce que je souhaite.

Tout est bon sauf les résidents. En fonction du bouton "locaux" et "ailleurs" et/ou en fonction du choix de la résidence, la liste varie. Mais elle n'est pas fidèle à ce qu'elle devrait être. 

Sans parler des présents, je devrai avoir Henry et Grattecap dans une, Vainqueur et Cheron dans l'autre. Là j'ai des combinaisons, d'un participant pour une et trois participants pour l'autre ou inversement

mon fichier : https://www.cjoint.com/c/MJohmg5sWTE

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
14 oct. 2023 à 10:08

deux erreurs dans la requête en #75

  1. il n'y a pas de vérification de la date d'entrée (petite erreur)
  2. (grosse erreur) tu confonds id_logement et id_residence
0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
14 oct. 2023 à 10:05

créez une requête distincte qui execute la première jointure, puis inserer cette requete dans votre instruction

  • supposons que tu décides de ne prendre que les logements étant associés à une résidence (premier choix dans cette jointure)
  • tu commences par créer une requête avec ces deux tables, et tu donnes un nom à cette requête (R_log_res)
  • tu crées ensuite une requête avec trois sources: la table personnes, la table residents, et la requête R_log_res
0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
14 oct. 2023 à 10:18

Suggestion pour organiser les requêtes pour faciliter le travail et pouvoir s'y retrouver, surtout si il est nécessaire de faire ensuite des changements

Ne pas tout faire dans la même requête, plutôt utiliser des cascades de requêtes.

Par exemple, pour obtenir la liste des candidats, je fais deux requêtes:

Une requête R_perso

SELECT T_personne.id_personne, T_personne.nom, T_personne.prenom, 
T_personne.categorie_personne, T_residences.id_residence, T_residences.nom_residence,
 T_residents.date_entree
FROM T_personne 
LEFT JOIN 
((T_logements LEFT JOIN T_residences ON T_logements.id_residence = T_residences.id_residence) 
RIGHT JOIN T_residents ON T_logements.id_logement = T_residents.id_logement) 
ON T_personne.id_personne = T_residents.id_personne;

Et ensuite une requête R_candidats:

SELECT R_perso.id_personne, R_perso.nom, R_perso.prenom, R_perso.categorie_personne, 
R_perso.id_residence, R_perso.nom_residence
FROM R_perso
WHERE
...

Cela permet aussi plus facilement de tester chaque requête, et de découvrir où cela cloche.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
14 oct. 2023 à 11:08

Je vais reprendre tes suggestions.

Je te remercie .

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
14 oct. 2023 à 13:50

Réponse au #77

--> pourquoi faire une vérification de la date d'entrée? Ce n'est pas plutôt la date de sortie. Résidents présents = ceux dont la date de sortie n'est pas renseignée.

-->effectivement, je les ai confondues et ça fonctionne mieux avec "id_residence". Je pensais que les relations existaient entre les tables résidence et logement mais non. Je ne les avais pas mis en relation car mon champs unique de la table résidence était déjà lié au champs "id_residence" de ma table financement. Est il possible de créer un lien entre mon champs unique "id_residence" de ma table "residence" et les champs "id_residence" de mes tables "financement" et "logement". C'est une pratique correcte ou pas?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
14 oct. 2023 à 13:59

Du coup, en corrigeant tes remarques du #77, la requête fonctionne.

SELECT T_personne.id_personne, T_personne.nom, T_personne.prenom, T_personne.categorie_personne, [Forms]![F_ajouter_suivi_activites]![endroit] AS Expr1, T_logements.id_residence, T_residents.date_sortie

FROM T_personne LEFT JOIN ((T_logements LEFT JOIN T_residences ON T_logements.id_residence = T_residences.id_residence) RIGHT JOIN T_residents ON T_logements.id_logement = T_residents.id_logement) ON T_personne.id_personne = T_residents.id_personne

WHERE (((T_personne.categorie_personne)=[Formulaires]![F_ajouter_suivi_activites]![filtre]) AND 

(([Forms]![F_ajouter_suivi_activites]![endroit])="I") AND 

((T_logements.id_residence)=[Forms]![F_ajouter_suivi_activites]![F_ch_id_residence]) 

AND ((T_residents.date_sortie) Is Null)) OR (((T_personne.categorie_personne)=[Formulaires]![F_ajouter_suivi_activites]![filtre]) AND (([Forms]![F_ajouter_suivi_activites]![endroit])="A") 

AND ((T_logements.id_residence)<>[Forms]![F_ajouter_suivi_activites]![F_ch_id_residence]) 

AND ((T_residents.date_sortie) Is Null)) OR (((T_personne.categorie_personne)=[Formulaires]![F_ajouter_suivi_activites]![filtre]) AND (([Forms]![F_ajouter_suivi_activites]![endroit])="T"));

Mais au regarde #76 et 78, il vaut mieux pour moi que je suive ta méthode.

Parce que l'étape suivant pour moi, c'est d'enlever les inscrits de la liste

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
14 oct. 2023 à 14:19

réponse au #80:

  • Date de sortie, en effet.
  • C'est une pratique correcte. 
0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
Modifié le 14 oct. 2023 à 14:29

réponse au #78.

Je crois que je comprends l'idée de requête en cascade.

dans la requête R_perso, tu prends tous les champs dont tu as besoin et tu paramètres les types de jointures entre les différentes tables

dans la requête R_candidats, tu récupères la requête R_perso, et tu viens ajouter toutes tes conditions.

C'est bien ça?

Après ce qui reste vraiment confus pour moi, ce sont les jointures. J'ai dû mal à me représenter la différence entre les différents choix. quel changement si je choisis tous dans telle table et seulement = dans l'autre. 

"Seulement les champs égaux", je ne comprends pas

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
14 oct. 2023 à 17:33

réponse au #84:

  1. oui
  2. <>, cela signifie "est différent de".  Dans le cas où endroit = "A", on  veut sélectionner les résidents dont la résidence est différente de la résidence de la séance
  3. la requête inscrits retourne toutes les personnes déjà inscrites à la séance en cours.  c'est cela qu'on affiche dans fille23.
    la requête candidats_non_inscrits combine la requête en #84 et la requête inscrits, et retourne tous ceux que donne la requête #84, à l'exception des inscrits.  C'est cela qu'on va afficher dans la liste a_participant.
0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
14 oct. 2023 à 17:51

Merci! Je vais essayer de réussir sans te solliciter 

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
15 oct. 2023 à 15:31

Bon je crois que j'ai réussi. En tout cas ça marche.

R_inscrit :

SELECT 
T_personne.id_personne, 
T_personne.nom, 
T_personne.prenom, 
T_personne.categorie_personne, 
T_participations.id_seance
FROM T_personne INNER JOIN T_participations ON 
T_personne.id_personne = T_participations.id_personne
WHERE (((T_participations.id_seance)=[Formulaires]![F_ajouter_suivi_activites]![F_ch_id_seance]));

Requête candidats non_inscrits

SELECT R_candidats.id_personne, 
R_candidats.nom, 
R_candidats.prenom, 
R_inscrits.id_personne
FROM R_candidats LEFT JOIN R_inscrits ON 
R_candidats.id_personne = R_inscrits.id_personne
WHERE (((R_inscrits.id_personne) Is Null));

Requête A_participant (zone de liste des participants à ajouter)

SELECT R_candidats_non_inscrits.R_candidats.id_personne AS Expr1, R_candidats_non_inscrits.R_candidats.nom AS Expr2,
 R_candidats_non_inscrits.R_candidats.prenom AS Expr3
FROM R_candidats_non_inscrits;

Est-ce la manière dont tu aurais procédé?

Après même si ça marche, je ne suis très "satisfait", je n'ai pas bien compris la logique. faut que j'y travaille encore. Je me suis servi de tes anciennes requêtes que j'ai adaptées aux nouvelles...

Il demeure juste un problème sur mon formulaire. Pourquoi "fille23", j'y ai accès manuellement alors que sur ton fichier, c'était figé? Je ne veux pas qu'on puisse apporter des modifications dessus. Comment as tu fait pour le verrouiller?

Merci pour tout!

(je pense à ajouter une nouvelle fonction sur le formulaire : pour la catégorie proche, ajouter une zone de saisie à partir de laquelle, on pourrait saisir manuellement le nom du résident et ainsi faire apparaître plus facilement les proches correspondant aux résidents dans la zone A_participant. Cela nécessiterait-il de repenser toutes les requêtes? Ou bien ce serait un petit bout de code en plus dans des requêtes indépendantes? Y a au moins A_participant qui sera impacté, ça c'est sûr!). 

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
Modifié le 15 oct. 2023 à 20:16

Réponse au #88:

  • oui, c'est ainsi que j'aurais fait
  • pour essayer de mieux comprendre les requêtes, tu peux faire ainsi: ouvrir le formulaire, cliquer sur les boutons.  Puis, en laissant le formulaire ouvert, ouvrir les différentes requêtes pour voir ce qu'elles retournent comme résultat.  Je pense que la requête obscure,  c'est la requête candidats non_inscrits.
  • comment figer "fille23": dans l'onglet "données" des propriétés (en mode création) du formulaire F_participations, tu as la possibilité d'autoriser ou d'interdire les ajouts, éditions et suppressions.  Tu as tout autorisé, moi je n'ai autorisé que les suppressions.
  • comment vois-tu la possibilité de saisir le nom du résident dont on proposerait les proches?   A partir des résidents déjà inscrits à la séance?
    Je m'attendrais alors à voir dans la table personnes un champ id_personne_proche, qui ferait le lien du proche vers le résident.
    Je pense qu'il faudra compléter (ajouter quelque chose) dans plusieurs requêtes, et peut-être insérer une requête dans la cascade.  La mise en cascade de requêtes ayant chacune un rôle facilitera ce travail.

EDIT:

Pour les proches, on pourrait simplement proposer tous les proches de tous les inscrits à la séance, ce serait assez simple à faire, et cela me semble raisonnable à l'utilisation, surtout si on montre pour chaque proche de quel résident il s'agit.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
15 oct. 2023 à 20:50

Merci pour ces éclaircissements et en effet,la requête non inscrit m'est encore très confuse.

Pour la suggestion des proches, le "problème " c est qu il n est pas impossible d avoir un proche de résident présent à l activité sans que le résident soit présent. On ne le rencontre jamais au quotidien mais il n est pas impossible que ce scénario se produise.

Je vais y réfléchir.

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
15 oct. 2023 à 21:51

La requête non inscrit fonctionne ainsi:

Prenons deux tables, chacune avec un champ, "id" dans les deux tables.

t1 contient deux enregistrements, A, B.

t2 contient deux enregistrements A, C.

t1 ce sont les candidates, t2 les inscrits.  et on cherche à  avoir la liste des candidats non inscrits, donc on veut obtenir seulement "A"

Que va donner "select t1.id, t2.id from t1 inner joint t2 on t1.id = t2.id"?

Que va donner  "select t1.id, t2.id from t1 left joint t2 on t1.id = t2.id"?

Tu peux tester cela dans Access.

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
16 oct. 2023 à 08:53

oups!  on veut obtenir seulement "B".

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
16 oct. 2023 à 13:22

Je vais regarder ça ce soir (Je n ai pas d accès à access aujourd'hui).

Merci d œuvrer à ma compréhension d access :)

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
17 oct. 2023 à 10:15

Réponse au #91:

Je trouve les mêmes résultats.

requête 1 : "select t1.id, t2.id from t1 inner joint t2 on t1.id = t2.id"

requête 2 : "select t1.id, t2.id from t1 left joint t2 on t1.id = t2.id"

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
17 oct. 2023 à 10:38

Je cherche à ajouter sur mon formulaire, un récapitulatif du nombre de participants par catégorie.

L'idée étant de pouvoir contrôler rapidement si tous les participants ont bien été ajoutés.

J'ai ajouté des zone de textes par catégorie:

- Résidents locaux : "Nb de résidents locaux"

-Résidents extérieur "Nb résidents extérieurs"

-Extérieurs " Nb extérieurs"

-Proches "Nb proches"

-Autres " Nb autres"

- Total "Nb participants"

Est ce que tu pourrais m'orienter sur la méthode à adopter ? Parce que tout ce que je tente c'est catastrophique...

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
17 oct. 2023 à 18:51

On a donc bien obtenu tous les éléments de t1 qui ne sont pas dans t2.

C'est ainsi qu'on obtient tous les candidats qui ne sont pas inscrits.

1
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
17 oct. 2023 à 11:25

réponse au #95:

Pour cela tu as besoin d'une requête des inscrits, avec la catégorie et la résidence.

Je suggère d'ajouter ces infos à la requête R_inscrit.

Pour cela, modifier R_inscrit et utiliser, comme source, R_perso au lieu de T_personne.

Cela fait, tu pourras associer, à chacune de tes zones de texte par catégorie, une expression utilisant la fonction dcount().
 

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
Modifié le 17 oct. 2023 à 13:05

Réponse au #98

J'ai remplacé la source T_personne par R_personne.

1.est ce que je dois garder T_personne afficher dans la requête? sachant que c'est T_personne qui fait le lien entre R_personne et R_inscrit? Ou bien dois je créer une relation entre R_personne et R_inscrit?

2. la fonction dcount :

- cela correspond à un champs calculé? donc cette fonction est à mettre dans la requête au niveau du champs?

-j'ai essayé d'exprimer la fonction mais elle ne passe pas. Ma tentative pour la catégorie exterieur:

Nb_exterieur:CpteDom("[T_participations.id=personne]";"[R_personne.categorie_personne]";"[R_personne.categorie_personne]"="EXTERIEUR",
 

- dans critère, je mets le champs : "Nb_exterieur"? (qui correspond au nom que j'ai attribué à la zone de texte qui va accueillir ce résultat)

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
17 oct. 2023 à 13:53
  1. Dans R_inscrit, il faut complètement remplacer la source T_personne par R_personne, donc créer une relation entre R_personne et T_participations
  2. dcount est à mettre dans la définition de la zone de texte du formulaire, comme valeur à afficher (par défaut) ou comme source du contrôle.  Sans doute
    dcount("*",R_personne,"categorie_personne='EXTERIEUR'")
0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
17 oct. 2023 à 18:17

réponse au #103

quand je rentre la formule

dcount("*",R_personne,"categorie_personne='EXTERIEUR'")

que ce soit en valeur par défaut ou source de contrôle, j'ai ce message d'erreur:

"Vous avez omis un opérande ou un opérateur, entré un caractère ou une virgule non valide, ou entré du texte sans le délimiter par des guillemets" .

J'ai bien essayé d'autres syntaxes mais toujours le même message.

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
17 oct. 2023 à 18:24

tu as essayé avec ; au lieu de ,  ?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
17 oct. 2023 à 18:33

réponse au #109

Je n'avais pas essayé les point virgule.

Je n'ai plus le message d'erreur, accès m'a transformé automatiquement ma formule en 

=CpteDom("*";[R_personne];"categorie_personne='EXTERIEUR'")

Par contre, dans ma zone de texte, j'ai une erreur "#Nom"

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
18 oct. 2023 à 17:09

Les compteurs d'inscrits doivent se baser sur la requête R_inscrits, et ne pas repartir des tables.

En regardant comment ajouter id_residence dans R_inscrits, je me suis rendu compte d'une erreur dans la requête R_personne.  Dans le cas où un résident a changé de logement.

Je pense qu'il faut créer une requête R_residents, qui part des tables residents, logements et residences, et qui ne garde que les residents ayant une date de sortie non nulle.

Ensuite, adapter la requête R_personne, qui combinera T_personne et R_residents.

Ensuite, adapter R_inscrits, pour reprendre aussi le champ id_residence de R_personne.

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
18 oct. 2023 à 17:34

L'autre façon de faire, non testée, ce serait de simplement ajouter le test sur date_sortie dans R_personne, de façon à éliminer les anciens logements des résidents, mais aussi d'éliminer les résidents sortis, ce qui n'est peut-être pas souhaitable.

Plus simple, mais, je pense, moins propre que ma suggestion précédente.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
18 oct. 2023 à 19:27

Rofl, moi qui croyais avoir trouvé tout seul. 

Je crois que j ai compris ta suggestion.

Je vais me remettre au boulot !

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
Modifié le 19 oct. 2023 à 08:55

Réponse au #132

Du coup, si je créé une requête R_residents.

Je dois enlever de la table_Residents, le champs "id_personne"?

Et si on prend, les résidents dont la date de sortie est non nulle. Cela signifie que la requête renverra tous les résidents qui ont quitté leur logement?

Enfin, pour exprimer, non null,comment fait on? <>Est null ne fonctionne pas?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
20 oct. 2023 à 15:00

Un résident qui est passé dans plusieurs chambres se serait retrouvé plusieurs fois dans l'ancienne requête R_¨personne.

Pour éviter cela, j'ai suggéré soit #132, soit #134.

1
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
20 oct. 2023 à 17:48

réponse au #150:

J'imagine qu'ils peuvent participer individuellement aux animations.  Je pense à deux options:

  1. Le plus simple est de les encoder comme deux personnes résidents dans la même chambre.  Cela me semble bien de les considérer le plus possible indépendamment.
  2. Tu dois gérer la facturation des logements, des personnes, ... ?  On pourrait aussi considérer la table résidents comme une table "occupation d'un logement", et faire une relation N à M entre la table personne et la table resident.
1
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
21 oct. 2023 à 14:12

Tu as toujours le problème #149?

Un résident qui a déménagé est compté comme 2 dans le compteur des inscrits résidents

Comme j'image les choses, il n'apparait qu'une fois dans R_personne, et tout le reste en découle.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
Modifié le 21 oct. 2023 à 14:47

réponse au #156

ah non! je n'ai plus le problème.

En fait je t'avais demandé pourquoi j'avais dû tout reprendre car quand j'étais dans mon formulaire, en apparence, ça ne changeait rien.

Tu m'as répondu que les modifications permettaient que dans R_personne, dans le cadre d'un déménagement, le résident n'apparaisse pas deux fois.

j'ai fait les essais entre l'ancienne méthode et la nouvelle: et effectivement tu avais raison, dans l'ancienne méthode, dans R_personne,en déménageant un résident, on le retrouve 2 fois dans la requête. Même s'il n'apparait qu'une fois dans la zone de liste A_participant. Et par ailleurs, dans l'ancien fichier, dans les compteurs , un résident qui a déménagé, que j'inscris dans une activité, compte pour deux.

Avec ta méthode tout est clean, je n'ai plus ces problèmes.

Là je viens de mettre au clair toute l'architecture des requêtes. Leurs dépendances et la manière dont elles s'articulent. C'est devenu vraiment plus clair. 

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
21 oct. 2023 à 14:53

ouf!  Je n'avais pas compris que le souci concernait l'ancienne version.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
Modifié le 22 oct. 2023 à 10:13

J ai tout reconstruit. Formulaires et requêtes.

C est bon. J ai bien assimilé toutes les étapes ^^

Je vais pouvoir m attaquer à la suite.

Mais je me pose une question. 

Si je souhaite cette fois, faire,  un suivi des repas. (Les résidents déjeunent ou non en salle et l idée c est de suivre chaque jour qui a dejeune ou non).

La démarche est quasiment la même que celle de la participation à des activités.  

Je vais devoir rajouter les tables en conséquence. 

Mais pour le suivi en lui même. Je repars sur deux formulaires ? Un consultation et un d ajout?

Et je recrée tout un système de requêtes?

Quelles seront les conséquences à la fin sur mon fichier, sachant que j aimerais sur ce modèle suivre pas mal de choses? (Latence?)

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
22 oct. 2023 à 10:46

"rajouter les tables": j'ai d'abord cru que c'était les tables de la salle à manger, que tu allais les ajouter comme objets dans ton fichier (et pourquoi pas).

Un formulaire d'ajout, je pense.  Parfois, les consultations se font via un état, qu'on peut ouvrir (filtrer) via un formulaire.  Les états sont plutôt destinés à imprimer des rapports.

Access est un système sophistiqué de base de données.  Si les tables sont bien conçues, il ne devrait pas y avoir de souci de performance.  De plus, tu resteras dans un volume d'enregistrements assez modeste, alors qu'Access peut en traiter des millions.

Si tu remarques des ralentissements, il sera peut-être utile, le moment venu, d'ajouter des clés (ou index) supplémentaires à des tables.  Des clés (permettant, ou pas, des doublons) permettent aussi à Access de retrouver beaucoup plus vite des enregistrements, ce qui accélère les filtres, tris et jointures.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
Modifié le 22 oct. 2023 à 12:35

OK, cool, c'est rassurant. Merci .

Je vais prochainement m'attaquer à la suite!

Le traitement d un fichier accès est facilité avec power BI? (puisque les relations existent).

Une conversion du fichier accès sur powerapps est elle possible?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
24 oct. 2023 à 15:51

Commence pas structurer tes tables autour des activités.

Si gym douce est une activité, il doit y avoir un enregistrement pour cette activité, pas deux.

Cela me semble une bonne idée d'enregistrer les prestataires comme des personnes. 

Quelle est le type de relation entre prestataires et activités?  Une activité peut avoir plusieurs prestataires.  Un prestataire peut-il prester différentes activités?

Par ailleurs, quel sont les relations entre activités, résidences et financements?  Explique cela en français.

Une séance, c'est bien le déroulement d'une activité à un moment donné, dans une résidence donnée?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
24 oct. 2023 à 20:11

Oui un prestataire peut animer des activités différentes et oui une meme activité peut-être animée par différents prestataires.

Une activité, dans notre contexte, est une action d animation animée par un prestataire à destination d un certain type de public.

Un financement est un moyen financier qui permet de mettre en œuvre des activités dans une résidence donnée. 

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
24 oct. 2023 à 21:19

Je pense donc qu'il y a une relation "de plusieurs à plusieurs" entre personnes (prestataires) et activités.

Des relations de ce genre s'enregistrent via une table supplémentaire spécifique.  Dans cette table, on enregistre les couples possibles (prestataire, activité).  Cette table, "capacités", enregistre qu'un prestataire est capable de prester un activité.  Cette table aurait 2 champs, id_personne et id_activite, et une clé primaire (unique) sur la combinaison de ces deux clés, pour empêcher d'enregistrer plusieurs fois le même couple.

Le financement s'applique à toutes les activités dans la résidence, ou seulement à certaines?  Plusieurs financements sont-ils possibles pour la même activité dans la même résidence?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
25 oct. 2023 à 10:39

Chaque activité relève d'un type de financement.

Plusieurs financements ne sont pas possibles pour une même activité.

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
25 oct. 2023 à 11:55

Chaque activité relève d'un type de financement.  Est-ce global pour l'activité, ou par résidence?

Si c'est par résidence, la table financements aura trois champs, id_activite, id_residence, et type de financement.  Pas besoin d'id_financement (source de confusion), la clé primaire (unique) utilisera la combinaison de id_activite et id_residence, pour empêcher d'enregistrer plusieurs financements pour le même couple.

La table financement enregistre, en réalité, la relation entre les activités et les résidences, indiquant que l'activité est organisée dans la résidence.

Je suppose qu'une séance qui a lieu dans une résidence doit être financée pour cette résidence?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
Modifié le 25 oct. 2023 à 16:52

Réponse au #176

Oui une séance doit être financée.

Pour chacune des résidences, toutes les activités relèvent d'un financement.

On distingue 3 types de financement, qui sont les mêmes dans les deux résidences.

Dans la résidence 1, on a financement A, financement B, financement C.

Dans la résidence 2, on a financement A, financement B, financement C.

Une activité relève soit du financement A, soit du financement B, soit du financement C.

Les activités ne sont pas forcément les mêmes d'une résidence à l'autre. En tout cas il faut les observer au regard de chaque résidence individuellement.

J'avais fait le lien entre les tables financement et activité via le champs id_financement.

Si je comprends bien, tu me proposes de faire le lien entre les deux tables via le champs id_activites?

Donc dans la table activité, je retire le champs financement?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
29 oct. 2023 à 09:19

Je reviens sur la table "intervenants" (capacites).

1.Je n'arrive pas à créer une relation plusieurs à plusieurs. J'ai 3 champs : id_intervenant, id_personne et id_activité. Mais quand je regarde les jointures dans les relations. Que ce soit quand ma table intervenant est reliée à celle de la table personne ou bien celle reliée à ma table activités, il est écrit type "un à plusieurs".

2. tu m'avais expliqué que d'une part, il vaut mieux renseigner une table via un formulaire et d'autre part qu'on ne construit pas sa table en vue du formulaire qu'on va vouloir créer pour la remplir.

Si je souhaite construire mon formulaire de la manière suivante : 

- choix de la résidence, choix du financement qui va permettre d'avoir une influence sur la liste des activités à selectionner

- choix de la catégorie de personne (j'ai ajouté : prestataire, personnel, partenaire) qui va influencer la liste des personnes à selectionner

parce qu'en l'état, si j'ai 200 personnes dans ma table personne, c'est un peu pénible pour la sélection, idem pour les activités.

ma question est la suivante : ma table intervenant, je la laisse qu'avec les 3 champs et je me débrouille avec le formulaire? ou bien je rajoute des champs "catégorie de personne", "type financement", "nom résidence" à ma table intervenant?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
29 oct. 2023 à 10:27

réponse au #218:

 table "intervenants" (capacites).

1.Je pense que le champ id_intervenant ne sert à rien.  La clé primaire doit être sur le couple (personne, activité).  La relation plusieurs à plusieurs entre personnes et activités n'est pas immédiatement visible, elle résulte des relations de chacune des tables avec la table intervenants.

2.  tout cela ne justifie pas d'ajouter des champs à la table intervenants.  ces données ("catégorie de personne", "type financement", "nom résidence") sont facilement récupérables via une requête. 

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
29 oct. 2023 à 10:36

réponse au #221

1. La clé primaire doit être sur le couple (personne, activité). Je ne comprends pas ça. Pour moi le champs id_intervenant, représentait la relation du couple id_personne/id_activité. Du coup, j'ai deux champs dans ma table intervenant? id_activité et id_personne? Comment j'associe ma clef primaire au couple?

2. ok, c'est compris. C'est dans ce sens là que j'ai commencé à construire mon formulaire

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
29 oct. 2023 à 11:28

comment associer une clé à un couple de champs?  regarde la définition des clés dans la table des participantions.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
29 oct. 2023 à 13:21

réponse au #224

dans ma table participation, la clef primaire est sur le champs "id_participation". C'est pourquoi dans ma table intervenant, j'avais un champs id_intervenant au format numeroauto. c'est donc bien lui qui défini la relation d'un couple id_activité/id_personne?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
29 oct. 2023 à 13:34

je pense que id_participation n'est pas utile et peut être supprimé.

ce qui "définit" un couple id_activité/id_personne, c'est la présence du couple dans la table des participations.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
29 oct. 2023 à 13:48

réponse au #229

donc je peux utiliser seulement mes deux champs id_activité/id_personne sans mettre de clef primaire?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
29 oct. 2023 à 10:53

pour éviter le souci en #217:

dans le formulaire, un changement de résidence ne va pas automatiquement changer le choix dans la liste des financements.

tu peux associer une macro à une mise à jour de la résidence, et, dans cette macro, changer la valeur du financement, peut-être la mettre à "?".

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
29 oct. 2023 à 13:32

réponse au #223

Je ne sais pas le faire. 

J'ajoute une action DefinirPropriété? Nom du controle : F_ch_id_residence/valeur:?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
29 oct. 2023 à 16:57

De quel contrôle veux-tu changer la valeur?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
29 oct. 2023 à 17:15

Réponse au #234

tu peux associer une macro à une mise à jour de la résidence, et, dans cette macro, changer la valeur du financement, peut-être la mettre à "?".

J ai du mal à me représenter le truc. 

Associer une macro à une mise à jour de la résidence. Une mise à jour de la résidence c est déjà une macro? "Associer une macro à ", ça veut dire une deuxième macro?

Et dans cette macro, changer la valeur du financement ? Pour changer la valeur du financement quelle macro je dois utiliser? Définir propriété ? Définir valeur? 

Peut être la mettre à "?"  . "?" A quoi correspond cette valeur? 

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
29 oct. 2023 à 18:59

Associer une macro à une mise à jour de la résidence.

Créer une nouvelle macro associée à l'évenement "après mise à jour" du contrôle F_ch_id_residence

dans cette macro, changer la valeur du financement

Fais comme tu as écrit en #228, à part que le nom du contrôle n'est pas correct.

Je propose de mettre le financement à "?", de façon à inviter l'utilisateur à choisir un financement.  Tu peux choisir un autre texte si tu préfères.

1
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
30 oct. 2023 à 06:59

Réponse au #239

Ok j'ai compris. ca fonctionne. Je te remercie.

le "?", je croyais que c'était un symbole comme "=" ou "<>". Je n'avais pas compris que le champs inscrirait simplement la valeur qu'on renseignerait.

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
29 oct. 2023 à 11:55

réponse au #220:

le souci vient de la définition du contrôle F_ch_residence dans le formulaire la colonne liée doit être l'id de la résidence, pas son nom.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
29 oct. 2023 à 13:25

réponse au #225

ah oui ok; ça fonctionne mieux en effet ^^

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
30 oct. 2023 à 07:14

Mais nouveau soucis.

Franchement, parfois, quand j'ai l'impression de faire un pas en avant, juste derrière je fais 5 pas en arrière avec Access.

J'essaie de construire mon formulaire "Intevenant" (capacité). 

J'étais assez fier, puisque j'avais réussi à intégrer dans mon formulaire tous les champs dont j'avais besoin pour guider et faciliter la saisie. J'avais associé toutes mes requêtes et ça se passait bien jusqu'à ce que je me rende compte de plusieurs choses.

1. quand je saisis dans mon formulaire mes enregistrements sont bien "sauvegardés" dans ma table intervenant mais si je ferme mon formulaire et que je le ré'ouvre, ils apparaissent vide "non renseignée". En fonction de ce que je sélectionne : résidence 1 ou 2, financement A,B,C et catégories de la personne, chaque enregistrement refait apparaître mes anciens choix.

Par exemple si l'enregistrement 1 et 2, j"avais choisi un financement 2 avec categorie d'intervenant "personnel", si dans un troisieme enregistrement je refais cette même selection, dans mes enregistrements 1 et 2 ces données réapparaissent.

2. par contre si dans un nouvel enregistrement, je change, le type de financement et la catégorie de l'intervenant, de nouveau mes enregistrements antérieurs se vident de renseignements. Sur le formulaire. parce que dans la table intervenant, ils restent bien renseignés.

Qu'est ce que je n'ai pas fait ou mal fait sur mon formulaire?

mon fichier : https://www.cjoint.com/c/MJEgnOQuamE

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
30 oct. 2023 à 11:12

Je ne suis pas expert en formulaires et comment gérer les interactions avec l'utilisateur.

Si je comprends bien, ton formulaire est conçu pour faire des ajouts, et fonctionne bien pour cela.

Et il fonctionne mal pour visualiser la situation.

Je pense à deux options:

  1. faire comme pour les inscriptions aux séances, où tu avais tout combiné dans un formulaire
  2. faire un formulaire d'ajout et un autre de visualisation/suppression 
0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
30 oct. 2023 à 11:48

OK merci,  je vais essayer

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
Modifié le 1 nov. 2023 à 10:44

Je remarque que mon champs "type_financement" dans mes tables "activité" et "séance"  est au format "textecourt".

Je me demandais si je devais le passer au format numérique.

En réfléchissant un peu, je me suis dit qu'on choisit un format numérique si dans les champs qu'on veut mettre en relation, il y en a un qui est au format "numéroauto". Est ce que mon raisonnement est correct?

L'autre question que je me pose par rapport à mon champs "type financement" que ce soit dans ma table activité ou séance, c'est est ce que le fait que mon champs soit au format "textecourt", cela ne me bloquera quand je voudrais faire des états? Par exemple faire un état de toutes les séances qui relèvent du financement A?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
1 nov. 2023 à 12:05

Une relation, c'est toujours via un champ à valeur unique, sans signification, qui ne devra jamais être mis à jour.  Le plus simple, c'est un nombre automatique.

Ici, comme il n'y a pas de table financement, type_financement, ce n'est pas une relation, c'est un attribut de l'activité, comme le prénom est un attribut de la personne.

Si tu avais une table financement, tu aurais un champ numérique automatique id_financement et un champ texte type_financement.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
1 nov. 2023 à 12:12

D accord, ça me rassure. Merci

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5
Modifié le 1 nov. 2023 à 14:59

je me rends compte que dans mon formulaire consultation activités, certaines informations ne restent pas renseignées.

en fait quand j'ajoute un nouvel évènement via le formulaire ajout activités, les informations sont bien renseignées dans la table "séance" mais dans formulaire consultation, certaines infos disparaissent (financement et intervenant disparaissent).

De même dans le formulaire ajout, le nom des activités des fiches renseignées dans le formulaire s'efface quand j'ajouter un nouvel enregistrement.

Alors pour intervenant, je suis en train d'essayer de créer un formulaire d'ajout et de consultation aussi.(je ne sais pas encore comment je vais ramener l'info intervenant après la création de ces formulaires) mais pour le champs financement de mon formulaire ajout, comment je peux faire pour qu'une fois mon formulaire renseigné, les infos soient conservées dans le formulaire de consultation?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474
1 nov. 2023 à 15:42

Si le formulaire ajout activités enregistre correctement les informations dans la table "séance", je suppose que le coupable, c'est le formulaire consultation, qui n'affiche pas les infos.  Quel est le nom de ce formulaire?

Si je comprends bien, tu appelles "ajout activité" le formulaire qui crée des séances?

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
1 nov. 2023 à 19:38

j'ai effectivement : 

- F_ajout_suivi_activite: pour celui créer les séances

- F_consultation_suivi_activite : pour consulter et modifier les fiches

Dans le premier formulaire, si je consulte les fiches, il manque toutes les activités déja renseignées (en revanche ces infos apparaissent dans la table séance)

dans le second, ce sont toutes les informations qui concernent les intervenants et les types de financement qui ne se maintiennent pas dans les fiches.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
2 nov. 2023 à 06:07

C'est bon, pour le formulaire consultation, j'ai réussi à trouver la source du problème.

Je n'avais pas modifié la requête du champs financement. J'avais laissé tel quel le champs après la suppression de la table financement. En modifiant la requête de son contenu, je recupère maintenant l'information, et elles bien stockée.

Pour le formulaire ajout, je n'y parviens pas mais je suppose que ce n'est pas grave puisque la fonction de ce formulaire est de créer les séances, non pas de les consulter? qu'en penses tu?

0
yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024 1 474 > badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023
2 nov. 2023 à 07:28

Pour le formulaire ajout, à toi de décider si il est utile de montrer, au fur et à mesure des ajouts, les séances déjà crées.  SI oui, tu pourrais t'inspirer de ce que tu as fait pour les inscriptions aux séances, où tu montrais la liste des inscriptions dans le sous-formulaire fille41.

Je trouvais que cela donnait un résultat très convivial, et je ne sais pas si c'est utile de faire ainsi pour l'ajout de séances.

Dis autrement, il est peut-être préférable, dans le formulaire ajout, de ne pas permettre de naviguer, et d'utiliser plutôt un bouton d'ajout.

0
badarledur Messages postés 397 Date d'inscription jeudi 1 janvier 2009 Statut Membre Dernière intervention 22 décembre 2023 5 > yg_be Messages postés 22864 Date d'inscription lundi 9 juin 2008 Statut Contributeur Dernière intervention 11 juin 2024
2 nov. 2023 à 09:35

réponse au #251

entendu, merci

0