MagalieJ

Bonsoir, C’est également ce que j’ai pensé mais les informations complémentaires données par @Niala semblent en fait justifier la présence de deux association dont l’une a un lien d’inclusion avec l’autre (on ne peut affecter un contact à une équipe que s’il appartient à l’édition de l’équipe).

Bonsoir ! Attention, il faut bien distinguer la récupération des données (ce que nous sommes en train de travailler) qui ne se produira qu’une seule et unique fois et l’utilisation quotidienne du fichier par la suite... C’est peut-être évident (et tant mieux), mais si ce n’est pas le cas, nous allons nous fourvoyer dans des impasses sans fin (un comble, pour une impasse !) Résumé de la structure La table SOC contient les informations concernant uniquement la société (principalement la Raison sociale) la table SIT contient les informations d’un site d’une société (type d

Même si ÉQUIPIER venait à disparaître, AFFECTER serait toujours là pour jouer son rôle de marieuse et les informations propre au CONTACT serait dans cette table. Je vois cependant deux rubriques qui effectivement peuvent remettre en cause cette structure... Pouvez-vous m’en dire plus sur Facture et Statut ? Votre graphe des liens est correct. Vous devriez donc être en mesure d’ajouter les informations souhaitées depuis l’occurrence de table CONTACT DANS ÉQUIPE. Vérifions peut-être les données et les liens : si vous créez une table externe de ÉQUIPIER (le « tout simple »), parvenez-vous à

Si vous inversez votre procédure, la table ÉQUIPIER devient inutile : les équipiers d’une édition devenant de facto les membres des équipes de l’édition ayant déjà été affectés. Mais c’est « en marge » de votre problématique actuelle. Comme je suis sur iPad, je n’ai pas accès au mode modèle sur votre fichier. J’espère ne pas faire de contresens par rapport à ce que vous avez mis en place. Sur votre modèle, basé sur Équipe, l’objectif est de pouvoir ajouter une nouvelle affectation en choisissant parmi la liste des équipiers de l’édition. Votre table externe doit donc être basée

En relisant les contributions précédentes, je me dit que cette approche à partir d’une table unique temporaire qui servirait à aller créer d’autres enregistrements ailleurs serait beaucoup plus adaptée en la combinant avec la recherche de doublon initiale.

L’idée de la table COM est effectivement de pouvoir avoir autant d’éléments de communication que souhaité : on pourra également enregistrer dans cette table le compte Skype ou le numéro de télex (comment ça je date un peu ? 😜) de la personne. En ajoutant une clé étrangère de Site dans la table COM, on pourra également y enregistrer les informations de communication propre au site : numéro du standard, adresse électronique « générique », etc. On peut même imaginer ajouter la clé étrangère de SOC et saisir dans la table COM le site web de l’entreprise par exemple. Votre scr

Bonjour ! Votre table ÉQUIPIER DANS ÉQUIPE est une table d’association qui sert donc à faire le lien entre un ÉQUIPIER et une ÉQUIPE. Personnellement, je l’appellerais AFFECTER pour traduire dans son nom ce rôle particulier de « marieuse ». Elle a besoin des clés étrangères de ÉQUIPIER et de ÉQUIPE mais pas de celle de CONTACT (ni de EDITION) car l’information est accessible via le lien entre ÉQUIPIER et CONTACT. Il est dès lors possible d’avoir deux enregistrements de AFFECTER pour le même ÉQUIPIER mais dans une ÉQUIPE différente. Questions subsidiaire : le choix des équip

De mémoire, le livre blanc sur la performance qui est sorti avec la v13 préconisait de préférer plusieurs tables, quitte même à avoir du 1 à 1, plutôt qu’une grosse table.

Bonsoir Excusez ma formulation malheureuse : c’est effectivement via un Définir Variable qu’il s’agit de « sauvegarder » les informations ! Avec 28 personnes et 22 données personnelles, le JSON serait vraiment opportun... mais vous devez pouvoir vous en sortir en reproduisant les précédents scripts. Ce sera un peu fastidieux pour l’écriture, mais rien d’insurmontable ! Par contre, pour la structure des données, je vous suggère d’avoir une table à part pour les données de communication. Cette table sera liée à la table Personne (donc une clef étrangère de Personne dans COM) et co

Bonjour, Pour moi, il n’y a pas plusieurs options : la règle de base et absolue est qu’on ne duplique jamais une donnée ! Une information qui appartient à MARQUE n’a donc rien à faire dans PRODUIT. La seule exception est le cas de la temporalité de l’information : s’il est par exemple important de conserver une valeur à un instant T (dans une facture, conserver le taux de TVA du moment d’établissement de la facture même si celui-ci a changé par la suite). J’utiliserai dans ce cas l’entrée automatique (ou le calcul mémorisé). Il existe aussi l’exception « fonctionnel » mais que j’utilise p

Bonjour ! Si je comprends bien la problématique, on a plusieurs personnes sur la même ligne et l’objectif est de créer les fiches correspondantes dans la table Personne. Il me semble inutile de recopier les informations dans d’autres colonnes. Voici comment je procèderais : -import dans une table temporaire du fichier Excel en l’état - pour chaque enregistrement (=boucle que vous maîtrisez bien maintenant ! 😉), sauvegarde dans des variables des valeurs nom, prénom et téléphone pour les 4 personnes de la ligne. Si les 4 personnes sont toujours remplies, je les mettrais simpl

Bonsoir, Prioritairement, il faudra bien définir les accès directement dans le jeu de privilèges. Il n’y aura pas forcément besoin de script.

Je rejoins mes petits camarades @Apophis000 et @Puimoisson04 : attention à ne pas structurer les données en fonction d’un découpage fonctionnel (ici, l’histoire des groupes et des congélateurs). La gestion des accès se fera beaucoup plus facilement via la sécurité, c’est-à-dire en créant quatre jeux de privilèges et en associant chaque utilisateur (=chaque compte) à celui qui lui correspond. On crée une table « groupe » et, dans une rubrique, on indique le nom du jeu de privilèges de ce groupe. Cette table Groupe, je la relie à la table Stockage préconisée ci-dessus par un lien 1 à N

La suggestion de @Apophis000 est plutôt pour l’utilisation courante de votre base par la suite. Dans le cas de vos scripts de mise à jour, je vous suggère de rester sur votre première version du script qui devrait faire le boulot.

Pour tout dire, il faut un « gestion erreur oui » avant le « exécuter la recherche » pour permettre de faire sauter le message d’erreur puis un « gestion erreur non » juste après le « exécuter la recherche » pour qu’il recommence gentiment à couiner dès qu’un truc le chagrine. Et le si va arriver à ce moment là et encadrer le remplacer.