Gérer les sous feuilles de données

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.

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.

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

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

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

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

je vais tester. Merci

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

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.

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.

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".

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.  

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.

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

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

réponse au #80:

• Date de sortie, en effet.
• C'est une pratique correcte. 

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

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.

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.

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

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

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. 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'")

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.

tu as essayé avec ; au lieu de ,  ?

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"

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.

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.

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

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?)

"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.

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?

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?

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

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

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?

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?

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

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?

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.

réponse au #229

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

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

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? 

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.

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.

OK merci,  je vais essayer

D accord, ça me rassure. Merci

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.

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?

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.

réponse au #251

entendu, merci