Puimoisson04

Bonsoir et bienvenu, Un bouton dans la table externe lançant l'action "Activer enregistrements liés".

Mais non, t'es pas tout seul David… C'est juste que (qu'on ?) n'a rien d'intéressant (ou pas) à dire.

Bonsoir, Sur le fond, je vous conseille d'avoir au moins un modèle "technique" basé sur une OT d'une table. Perso., j'y mets toutes les rubriques et au cours du développement tout ou partie des rubriques liées ou TE d'un aspect de la base en cours de développement. Ça permet de travailler à développement en ayant tous les éléments nécessaires sous les yeux le temps de régler un problème donné. Une fois le développement terminé vous pouvez supprimer ce modèle ou le masquer dans la gestion des modèles. Pour Articles/Matériaux, c'est un problème classique quand on commercialise à la fois des

Si une adresse ne correspond qu'à un contact, oui, une table Adresses est la meilleure solution. Vous y mettez une rub. IdConcact que vous liez à IdContact de la table Contacts et le tour est joué. Si plusieurs contacts ont la même adresse, il vous faut en plus une table intermédiaire avec IdContact et IdAdresse. À partir d'une OT de Contacts, la chaîne de liens sera : TableContacts/IdContact = IdContact/TableIntermédiaire/IdAdresse = IdAdresse/TableAdresses.

Bonsoir, Il vous faut modifier un peu la structure avec une table Évènements. Dans Affaires un autolien sur l'identifiant de l'évènement vous permet alors d'afficher tous les évènements identiques dans une TE. On est dans la même logique. Dans l'absolu, une table des Services et, dans les chaînes de liens concernées, un autolien sur l'IdService. On peut simplifier en faisant le lien directement sur le nom du service (ici pour l'exemple), mais c'est en fait une très mauvaise idée comme, sauf cas particulier, tous les liens sur un intitulé. Albatros3r.fmp12.zip

1. Une clé est une rubrique comme une autre. Si elle n'est pas primaire, impliquée dans un calcul, un script, une mise en forme ou n'est pas liée elle n'a pas d'incidence sur le fonctionnement de la base (mais on se demande alors si elle est bien utile). 2. Variable de fusion, rubrique globale ou variable globale utilisée dans des scripts ? Si on parle de rubriques globales, elles ont l'avantage d'être accessibles sans lien à partir d'une autre table, l'inconvénient (si cela en est un), de ne pas pouvoir être la cible d'un lien. On en revient aux fondamentaux et donc au cqfd qui expliquent

Bonjour, À défaut de "refaire" votre application (mais Apophis a raison, ce serait probablement la meilleure solution), vous pouvez prendre un peu de temps pour suivre le cqfd de FileMaker. Il explique bien toutes ces notions élémentaires de FileMaker… Vous verrez par exemple, ce qui ne semble pas encore très clair pour vous, la différence entre Table et Occurrence de table qui sont probablement les deux éléments les plus importants pour comprendre le fonctionnement de FMP. Oui, j'utilise le principe "ancre/bouée(s)" (il y a d'autres systèmes, cf. le cqfd) car je trouve qu'il facilite la l

Bonjour, Pas disponible aujourd'hui, mais je vous répondrai ce soir (si personne ne le fait dans la journée).

Donc si je comprend bien, à une affaire correspond un lieu unique. On a un identifiant unique pour chaque lieu (table Lieux) et, dans la table Affaires on a une rubrique IdLieu liée à IdLieu d'une occurrence de table de Lieux. Le lien = va permettre de "voir" les données de l'enregistrement de Lieux dont l'identifiant est saisi dans la rubrique IdLieu de Affaires. Donc, pour répondre à votre question, le IdLieu de Affaires doit être renseigné avec l'identifiant d'un lieu (selon toute logique, celui du lieu correspondant à l'affaire). Et pour avoir la liste des Id des lieux, on crée une l

Bonjour, À vrai dire, je ne comprend toujours pas la question ! Pour ce qui nous intéresse, on a donc deux tables, Affaires et Lieux. Soit ces deux tables avec leur identifiants uniques, IdAffaire et IdLieu. Les relations possibles entre ces tables. 1. À une affaire correspond un seul lieu (et ce lieu n'est "utilisé" que pour cette affaire) ou une affaire a plusieurs lieux mais ces lieux ne concernent que cette affaire. C'est à dire que dans tous les cas, un lieu ne concerne qu'une affaire. On crée une rubrique IdAffaire dans la table Lieu que l'on lie à IdAffaire de la table Affaires.

Bonjour, Comme vous le pressentez, la première chose est de définir les ensembles homogènes de données dont vous allez avoir besoin, chacun de ces ensembles constituant une table de votre fichier. Cette première étape qui peut sembler un peu abstraite est cependant essentielle car c'est elle qui va définir le développement (les relations) à mettre en place ensuite et influer directement sur la facilité de ce développement. Une fois ces "référentiels" définis, il faudra se pencher sur la manière de les mettre en relation. De ce que vous écrivez, on imagine déjà les tables suivantes . -

Bonjour, Une série des deux pas de scripts pour exporter en pdf ? Définir variable ($Pdf1 ; Valeur : Chemin et nom 1 ) Sauvegarder en pdf Définir variable ($Pdf2 ; Valeur : Chemin et nom 2 ) Sauvegarder en pdf Définir variable ($Pdf3 ; Valeur : Chemin et nom 3 ) Sauvegarder en pdf

Bonjour, Une copie d'écran du graphe de liens avec les occurrences de tables (développées) concernées permettrait peut-être de se faire une idée.

Bonjour, À ma connaissance, pas de jours ouvrables de manière native. Pour les WE, il y a des fonctions personnelles. Pour les jours fériés, je ne sais pas…

Bonsoir, Une mise en forme conditionnelle avec Obtenir (DateActuelle) > Date.