Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Effectivement, FileMaker permet d'indexé une rubrique avec un calcul qui contient "Obtenir(DateActuelle)" mais le problème est qu'une fois évalué et indexé, le calcule n'évolue plus et donc les jours passent mais le résultat reste le même. C'est pour cette raison que dans ce genre de calcul il faut que le développeur coche de ne pas indexer la rubrique. Ainsi le résultat sera réévalué à chaque besoin (affichage, recherche, tri....). Le soucis dans ton cas est que pour qu'un lien fonctionne la/les rubrique(s) de destination doivent être indexée - ce qui ne serait plus le cas. Donc il faut trouver une autre manière de travailler cfr mes pistes : calcul non mémorisé dans la table d'origine, ou filtre. bien à toi, Tanguy
  3. Bonjour Tanguy. Pourtant, FileMaker l'a bien indexé et les liens de mes occurences de table fonctionnent. Si j'ai bien compris FileMaker ne permet pas l'indexation lorsqu'un élément du calcul provient d'une autre table, ce qui n'est pas le cas de la rubrique "Jours_Écoulés|Calc" qui est égale à : Obtenir (date actuelle) - Date_Ouverture.
  4. On peut associer un déclencheur à l'ouverture du popover mais ce serait déjà un peu trop tard... Le mieux est de créer un bouton avec un script qui invite à se reconnecter et si OK ouvre un popover. Comme ceci : Pop.fmp12 (login admin / pwd vide )
  5. Bonjour, Je désire demander à un utilisateur son id et mot de passe afin qu'il puisse accéder au contenu d'un popover. comment procéder ? Merci
  6. Bonjour, Ce type de calcul ne peut être mémorisé (indexé) car la date du jour change chaque jour 😉 (dure réalité...) Si ces rubriques sont dans la table C et que le souhait est d'opérer un lien, ce lien sera inopérant dans le cas où il aboutit à des rubriques non mémorisées. Je conseille dès lors de placer dans la table au départ du lien des rubriques non mémorisées avec le calcul de la date du jour + x et de faire le lien vers la date du bon de commande. Sans doute possible aussi de fonctionner avec des filtres sur des tables externes mais attention aux calculs éventuels de sommes, moyennes,...qui ne sont pas impactés par les filtres. Cordialement, Tanguy
  7. Bonjour, Idem pour les individus constituants les équipes, il ne semble pas y avoir de table ¨MEMBRES ÉQUIPE¨. Cordialement.
  8. Bons_Commandes|60Jrs = Si ( Ouvert|Fl ; Si ( Jours_Écoulés|Calc > 60 ; 1 ; "" ) ; "" ) Ouvert|Fl indique si le bon de commande est ouvert ou fermé, car seuls les ouverts sont requis
  9. Last week
  10. Oui oui j'avais bien compris . Ton but est bien de trier les bon de commande en 3 partie selon date ? Alors mon systeme est ok, tu remplace 6 rubrique par une seul . Et tu peu, par ex, afficher dans 3 TE filtrée, chaque plage . Maintenent tu veux utiliser un booléen ...OK mais un Booléen c'est que 2 valeur 0 ou 1 , oui ou non , ... Alors comment tu fait pour avoir 3 valeur . Je suis curieux de voir ton calcule .
  11. Bonjour je pense que tu as un problème avec les tables il doit y avoir une table activités et une seule avec dans cette table un statut brevet contrat essais clinique etc... je pense qu'il faudrait reprendre l'analyse pour mieux définir les tables nécessaires et faire un organigramme bon courage
  12. Bonjour Apo, Je ne calcule pas exactement la même chose. Un calcul non mémorisé ne pourrait être indexé. Dans la TABLE_C J'ai 3 rubriques de calcul qui indiquent de façon booléenne dans quelle plage (0-30, 31-60 ou 61+) se trouve le bon de commande. Cette valeur booléenne sert à faire un lien sur 3 occurences de la TABLE_C vers la TABLE_B où 3 rubriques de calcul font la somme des bons de commande se trouvant dans chaque plage d'échéance. Cela fonctionne très bien pour les deux premières plages, mais pas pour la troisième. Le calcul est pourtant le même. J'ai refait l'index de la rubrique. J'ai recréé une autre rubrique que j'ai utilisée avec le même calcul, rien à faire. J'ai trouvé une parade qui fonctionne dans un script : De la TABLE_A j'active l'enregistrement lié de la TABLE_B dans une nouvelle fenêtre, puis de la TABLE_B, j'active les enregistrements liés de la TABLE_C. Merci pour le suivi
  13. Bonjour Gilles Si je comprends bien, tu as 3 rubrique de calcul dans ta table c et 3 autre dans ta table b ?? Tu calcul donc deux fois, la même chose dans 2 table différante. Le risque d’erreur vient plus que probablement de là. Je pence que tu a pas besoin de 3 rubrique pour un tri de ce type. Si tu remplaces dans ta table c les 3 rubriques par une seule appelé par exemple « NB_Jours » . Qui elle serai un calcule non mémoriser du type CAS , qui te renvoie « 1 « si la date a mois de 30 jours , « 2 » si +30 jours et « 3 » si + de 60 jours . ex: Cas ( Date > Obtenir(DateActuelle)-30 ; 1 ; Date > Obtenir(DateActuelle)-60 ; 2 ; Date < Obtenir(DateActuelle)-60 ; 3 ; 0 ) Ensuit, en mode liste par exemple, il suffit de faire une simple recherche sur la rubrique « NB_Jours » des 1 pour -30j , des 2 pour +30j et des 3 pour les plus de 60j … ++Apo
  14. Scripts et performance Nous avons vu la semaine dernière que certaines actions de script, ou certaines manières de les séquencer fait que des données circulent inutilement entre le serveur et le client. Dans le même ordre d’idée, il y a certaines tâches où l’on pourrait éviter ce transfert de données, non qu’il soit inutile à […] Afficher la totalité du billet
  15. Bonjour, Pour mettre en contexte mon problème, j'ai trois tables reliées de la façon suivante : TABLE_A ==> TABLE_B ==> TABLE_C. La TABLE_B est une TE d'unités où plusieurs bons de commande (TABLE_C) y sont attachés. La TABLE_C est déclinée en trois occurrences, soit : TABLE_C_Moins30 (moins de 30 jours), TABLE_C_Plus30 (plus de 30 jours) et TABLE_C_Plus 60 (plus de 60 jours) Dans la TABLE_C, j'ai 3 rubriques (calcul, type nombre) indexées, chacune indiquant si le bon de commande a moins de 30 jours, plus de 30 jours ou plus de 60 jours par une valeur booléenne (utilisées pour les liens). Alors pour la TE TABLE_B, j'ai 3 rubriques calcul (somme de chacune des 3 rubriques de la TABLE_C) où par exemple un enregistrement indiquera 3 (moins de 30 jours), 5 (plus de 30 jours) et 8 (plus de 60 jours). Chacune des 3 rubriques est un bouton exécutant un script (exécuter recherche) permettant d'afficher les bons de commandes moins de 30 jours, plus de 30 jours ou plus de 60 jours. Pour les deux premières rubriques, pas de problème. Pour la troisième, il devrait, comme dans mon exemple, afficher 8 bons de commandes, alors qu'il n'en a trouvé que 6. J'ai bien vérifié et la rubrique "plus de 60 jours" affiche bien la valeur booléenne de 1 pour les deux enregistrements manquants. Le résultat est aléatoire, c'est à dire que pour chaque enregistrement de la TABLE_B le résultat de la recherche sera parfois exact et parfois incomplet. Ce qui est bizarre, c'est que la somme de bons de commande s'affiche correctement dans la ligne de la TE, mais est aléatoirement incomplet à la recherche par script. Autre chose que j'ai remarqué, c'est que les bons de commande manquants sont généralement les plus anciens. Merci à l'avance.
  16. Alors là ! Que vous dit le debugger ? Peut-être avez-vous changé le nom du fichier ou de la liste de valeurs des langues ? En reprenant le principe vous devriez trouvez ce qui cloche. 1. Dans la table IFP__InterFonctionPersonnel, on a un enregistrement par couple personne/langue avec une rubrique texte FiltreCible à autoentrée calculée 1¶langue. 2. Dans la table FIL__Filtre, une rubrique globale texte, avec une liste de valeur des langues, liée = à FiltreCible. Dans FIL__Filtre, on veut que si aucune langue n'est cochée, la TE FIL->IFP affiche tous les enregistrements de IFP, mais que si une ou plusieurs langues sont cochées, seuls les enregistrements correspondants à cette(ces) langue(s) s'affichent. 3. Par défaut la rubrique Filtre_g est égale à 1. On voit alors à travers le lien tous les enregistrements de IFP puisque toutes les rubriques FiltreCible contiennent 1. 4. Si on coche une ou plusieurs langues, le script efface la valeur 1, ne laissant que la(les) langue(s) cochées. On ne voit plus alors à travers le lien que les enregistrements de Fonctions correspondant aux langues cochées dans Filtre_g puisque la rubrique cible contient la langue. 5. Et le script remet la rubrique Filtre_g à sa valeur par défaut (1) si on décoche toutes les langues. Le script est activé à la modification de Filtre_g. Si la modification de Filtre_g entraîne l'absence de valeur (le SI du script avec EstVide, si aucune langue n'est cochée), le script définit Filtre_g avec 1. Sinon, (le Sinon), le script définit la rubrique Filtre_g avec les seules valeurs comprises dans la liste de valeurs des langues. La fonction ElementsListeValeurs demande le nom du fichier (FiltreRecherche) et le nom de la liste de valeurs (Langues). Ex. Aucune langue n'est cochée, Filtre_g = 1. On coche Italien, la rubrique FIltre_g contient alors 1¶Italien. Cete modification déclenche le script. La rubrique n'etant pas vide, le script va réaliser le SINON du script et filtrer Filtre_g avec les valeurs de la liste des valeurs Langues (et supprimer le 1 ui ne figure pas dans cette liste de valeurs). En espérant que ces explications vous aident…
  17. Merci beaucoup pour votre reponse. Bon je vais regarder ca.. Bien à vous
  18. J'ai la version FM 17 Pro et lorsque je clique la première fois sur une des cases à cocher, la table externe se vide et les cases à cocher deviennent inaccessibles... De plus, en regardant le script, je ne comprends pas la seconde définition de rubrique, notamment d'ou provient "FiltreRecherche" définissant ElementsListeValeurs merci pour vos réponse.
  19. il faut utiliser une rubrique statistique, et non la fonction décompte dans un calcul. attention, autre point : tu dis utiliser un calcul pour IDseminaire, mais il faut utiliser un calcul auto-entré et non une rubrique calcul, sinon le jour où pour x raison tu voudras importer des données, ce ne sera pas possible.
  20. isb

    question facile

    merci - dommage - en fait je travaille sur 3 voir 4 fenêtres en même temps d'un même enregistrement (et avec des modèle différents...) c'est sans doute qu'il faut retravailler mes vieux modèles... Merci
  21. tcolles

    question facile

    Un enregistrement ne peut être modifié à deux endroits en même temps (deux fenêtres, deux utilisateurs,...) Donc il faut que à 1 des 2 endroits, l'enregistrement soit validé (clic en dehors des rubriques par exemple)
  22. Bonjour, Pour presque tout savoir sur la validation de rubrique : https://fmhelp.filemaker.com/help/17/fmp/fr/index.html#page/FMP_Help/field-validation.html bien à toi, Tanguy
  23. Bonjour, C'était la bonne solution. Merci @temp007
  24. isb

    question facile

    s'il vous plait une question facile je ne veux plus voire cette fenêtre je vous tout enregistrer en passant d'une fenêtre à l'autre direct Comment on fait ?
  25. Bonjour, Si, l'exemple fonctionne. Il fait appel à un déclencheur de script et des fonctions ajoutés au fil du temps aux versions successives de FMP. Le pb. vient peut-être de là ? Quelle version de FMP utilisez vous ?
  26. Merci beaucoup, Peut on rendre le message me signalant que la rubrique est prévue pour ne contenir que certaines valeurs bien précises par un message plus compréhensible ? bien à vous
  1. Load more activity
×
×
  • Create New...