Jump to content

Benoît Audibert

Membres
  • Posts

    21
  • Joined

  • Last visited

Profile Information

  • Gender
    Homme
  • Location
    Bruxelles/Paris
  • Interests
    Course à pieds, Histoire, Physique (mécanique quantique)

FileMaker Profile

  • FM
    FMS 19
  • OS
    OSX 10.15
  • Claris Partner
    --Non membre--
    Membre
    Platinum

Benoît Audibert's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. Ah oui ! Compris. En plus, cela permet d'économiser une rubrique, vu que je mets systématiquement une rubrique zk_1 dans toutes mes tables. Merci.
  2. Merci Jérémie pour ta réponse. Bien noté la distinction entre actif et ouvert. Pour l'instant, la solution que j'avais mise en place correspond, je pense, à la première possibilité que tu évoque. J'ai effectivement une rubrique dédiée qui est mise à 1, et j'ai un test en début de script qui interdit à tout autre utilisateur d'accéder à l'enregistrement en vu de le modifier (il peut uniquement y accéder pour le consulter) tant que cette rubrique n'a pas été remise à 0 par le premier utilisateur (dans mon cas lorsque celui-ci quitte l'enregistrement après l'avoir modifié). Ce que je souhaitais en fait c'est que la mise à 1 ou 0 de cette rubrique puisse se faire sans script (i.e. que la rubrique soit une rubrique calculée avec une fonction Obtenir). Mais je comprends que ce n'est manifestement pas possible, puisque la fonction Obtenir ( EtatEnregOuvert ) ne concerne que la session de l'utilisateur. Dommage ! Par contre, je ne comprends pas la seconde possibilité que tu évoque dans ta réponse, à savoir le test d'accès et le code erreur généré par ce test. Peux-tu préciser ? Merci d'avance.
  3. Bonjour, J'utilise FM 19 Server. Dans un script, je souhaite pouvoir exécuter des actions différentes selon qu'un enregistrement donné est actif, ou non, sur au moins un des postes clients. Idéalement, je souhaiterais que chaque enregistrement de la table concernée ait une rubrique booléenne enregistrant la valeur 1 si l'enregistrement est actif sur au moins un poste client. Y-a-t-il une fonction "Obtenir" permettant de faire cela ? Ou bien une autre méthode ? Merci d'avance pour votre aide.
  4. Ai trouvé ceci (FileMaker 16 - Dynamic Data Source) qui explique notamment comment scripter la définition de la variable globale. file:///Users/benoitaudibert/Documents/FileMaker/Documentation%20technique/FileMaker%2016%20-%20Dynamic%20Data%20Source.webarchive Très clair. Il y même une app démo (3 fichiers joints) que je m'empresse de regarder. Donc en opérant successivement comme suit : 1. ouvrir le fichier Interface sur un modèle ne se référant à aucune table externe (afin d'éviter le message d'erreur à l'ouverture "Source de données non trouvée") 2. puis lancer le script permettant la définition de la variable globale (ce qui évite d'utiliser la boîte de dialogue de gestion des sources de données externes) Ça devrait être bon. Du moins j'espère. Toutefois, il reste le point de savoir si cela est jouable avec un seul fichier Interface pour tous les clients, ou bien s'il est plus raisonnable de livrer un fichier interface distinct à chaque client. Dynamic_Data_Source_Demo_Interface.fmp12 Dynamic_Data_Source_Demo_Data_Source_1.fmp12 Dynamic_Data_Source_Demo_Data_Source_2.fmp12
  5. La solution est peut-être ici https://community.claris.com/en/s/question/0D50H00006tiOD4SAM/how-do-i-set-a-global-variable-as-an-external-file-reference-without-opening-the-data-file-as-hidden) Mais, à première lecture, cela dépasse mes connaissances actuelles. HELP !
  6. Ai trouvé une discussion dans Claris FM Community qui aborde ce point (voir pdf attaché - Nota : seule la première réponse de la discussion nous intéresse ici). La solution comporterait 3 fichiers : 1 Login file qui permet d'identifier le client (et donc le bon Data file à utiliser), 1 User file qui correspond à la structure et N Data files, autant qu'il y a de clients. Cela fonctionnerait grâce à l'utilisation d'une variable pour identifier le fichier de données à sélectionner comme source externe. Malheureusement, il n'y a pas plus de détails sur la manière d'utiliser précisément cette variable. Je continue de creuser ! Multiple users Same app differentt data — FileMaker Community.pdf
  7. J'ai trouvé beaucoup d'éléments de réponse sur le sujet "Separation Model" ( 1 fichier User Interface et 1 ou +sieurs fichiers Data) sur le forum Claris FileMaker Community. J'en retire que, sous réserve de prendre un certain nombre de précautions, par exemple en matière de gestion de la sécurité, le "Separation Model" semble bien adapté pour des solutions ayant vocation à être commercialisées. Je continue de m'informer, mais je suis de plus en plus tenté d'adopter cette approche pour mon prochain développement. Je reste preneur de vos avis et conseils, notamment si vous avez rencontré des difficultés inhérentes en employant cette méthode.
  8. Bonjour Jérémie, Merci pour ta réponse. Je pense que je vais donc en rester à ma méthode un peu "lourde" de variables globales. Après tout cela fonctionne. J'avais effectivement vu la possibilité d'obtenir toutes les ID et noms des listes de valeurs, mais comme toi, je me demande à quoi cela peut-il bien servir. En tout cas, je n'en ai pas trouvé l'utilité pour la question qui m'intéresse.
  9. Bonjour, Je cherche un moyen pour pouvoir changer à volonté le nom d'une liste de valeur sans que cela n'affecte mes rubriques calculées utilisant la fonction ElementsListeValeurs ( NomFichier ; ListeValeurs ). Le moyen que j'utilise actuellement est de définir à l'ouverture de ma solution des variables globales dans lesquelles je stocke les noms de mes listes de valeurs, puis j'utilise la variable globale adéquate pour désigner le paramètre ListeValeurs à chaque utilisation de la fonction ElementsListeValeurs. Lorsque me prends l'envie de changer le nom de l'une de mes listes de valeurs, je redéfini simplement la valeur de la variable globale correspondante. Je ne trouve pas cela très "élégant". Ai-je loupé quelque chose ? En effet, changer à volonté le nom d'une rubrique ne pose aucun problème, alors comment cela se fait-il qu'il n'en soit pas de même pour le nom d'une liste de valeurs ? Merci d'avance pour vos avis.
  10. Bonjour Jérémie, Merci d'alimenter ma réflexion. D'accord avec toi sur le cas du même lien nécessaire à la fois dans le fichier Structure et dans le fichier Data. Il reste juste la satisfaction, bien faible certes, de savoir que le graphe de lien de la Structure n'est pas "pollué" par des liens qui ne seraient nécessaires que pour un calcul ou une auto-entrée. J'ai essayé de paramétrer la source de données avec une variable globale, mais je rencontre deux difficultés : 1. Au lancement de l'interface (i.e du fichier Structure) celui-ci ne connait pas encore le contenu de la variable globale et ne parvient donc pas à identifier la source de données. Je réfléchis à inverser, en ouvrant d'abord le fichier Data puis le fichier interface. 2. Une fois l'interface ouverte, je lance le script qui définit la variable globale correspondant à la source de données, mais je n'ai pas trouvé l'action de script qui permette de valider le lien vers cette source. Je n'y parviens qu'en utilisant la commande du menu "Gérer les sources de données externes..." Je suppose qu'il doit exister une action de script correspondante. A moins que la solution que j'envisage au point 1. ne résolve également ce point 2. Je vais tester cela. Sur le point de la performance, ne gagne-t-on pas à avoir les fichiers Data de chacun des clients également sur le serveur ?
  11. Jérémie, suite à ta réponse, j'essaie d'imaginer néanmoins des avantages à la solutions à 2 fichiers : 1. Avoir les liens calculs et auto-entrées entre tables dans le fichier Data permet d'alléger visuellement le graphe de liens dans la table Structure 2. En cas de commercialisation de la solution à plusieurs clients, cela permet de n'avoir besoin que d'un seul fichier Structure installé sur le Serveur pour tous les clients. Je suppose que s'il n'y a pas, ou peu, de scripts exécutés sur le serveur, cela ne devrait pas ralentir le fonctionnement de la solution pour chaque client. Sur le point 2, je ne suis toutefois pas certain que cela soit techniquement viable, voire que cela soit autorisé par la licence FM. Qu'en penses-tu ?
  12. Merci Jérémie pour ta réponse. Cela n'incite effectivement pas à opter pour une solution à 2 fichiers, s'il n'y a par ailleurs aucun avantage évident pour la maintenance.
  13. PS : petite coquille dans ma question initiale, les liens entre les occurrences de tables sont dans le fichier structure et non pas dans le fichier données, celui-ci ne comportant que les tables.
  14. Merci pour ton conseil. Toutefois, je me demande si le process d'exportation/correction que tu suggères ne fonctionnerait pas également avec le fichier comportant uniquement des données.
  15. Je suis en train de développer la Version2 d'une solution existante. Contrairement à la Version1 vendue à un seul client, la Version2 a vocation à être commercialisée auprès de plusieurs clients. La solution fonctionne sur FM Server 19 La V1 regroupe dans un même fichier la structure et les données. Pour la V2, je m'interroge, notamment en terme de maintenance ultérieure, sur l'utilité de séparer en 2 fichiers distincts la structure (modèles, listes, scripts) d'une part et les données (tables, liens) d'autres part. Pouvez-vous me donner votre avis sur les avantages et inconvénients d'une solution à 2 fichiers distincts versus 1 seul fichier ? Merci.
×
×
  • Create New...