Script de recherche avec variable
Le but ici n'est certainement pas de faire le script de recherche le plus sophistiqué du monde, mais d'apprendre à utiliser une variable au sein d'un script. Travaillons sur un exemple concret, et décrivons d'abord ce que l'on veut :
DescriptionDans notre fichier, partir du modèle INS_Fiche, on aimerait contrôler si il existe plusieurs fois le même nom de personne dans la table PER_Personnes. Ainsi, on peut détecter un frère, un doublon, etc… La rubrique concernée est ins_PER__Eleves::Nom. La recherche devra donc se faire dans la table des PERsonnes. A côté du nom repris sur le modèle INS_Fiche, on peut placer un bouton d’un script qui va :
On pourrait imaginer aussi que, dans le contexte de départ des inscriptions, si un seul nom est trouvé un message indique que cette personne est unique et que l'on reste sur notre modèle d'inscription pour, justement, procéder à cette inscription. Au travail ! On crée un nouveau script appelé "RechercheNom" (Nomenclature comme d'hab' : pas d'espace, écriture Camel, éventuellement des "_" pour regrouper), en-tête duquel on peut placer notre intro habituelle. On peut également, pour les heureux détenteurs d'une version 9 et plus, créer un nouveau groupe appelé "Recherches". Définir une variableLa première chose à faire, vu qu'on est sur le modèle INS_Fiche et que nous allons ensuite changer de contexte, est d'embarquer dans une variable le nom présent sur le modèle, dans la rubrique ins_PER__Eleves::Nom. Pour ce faire, notre première action spécifique sera liée à la commande "Définir variable" :  Une variable de type $ suffit amplement, vu que nous n'en aurons besoin qu'au sein du même script. Le scriptVoici le script complet :  Gestion erreurComme précédemment, on démarre le script en précisant ""Gestion erreurs" = Oui, cela veut dire qu'on prend la main à FileMaker Pro pour gérer nous-même les erreurs. Le seul contrôle que l'on va effectuer pour l'exemple ici est de s'assurer qu'il y ait au moins un enreg. trouvé après la recherche. Si aucun enreg. n'est trouvé, une erreur est rendue et on peut la capter via la commande Si [Obtenir ( DerniereErreur ) ≠ 0] La RechercheDès qu'on a défini et complété la variable, on peut quitter le modèle INS_Fiche et aller su run modèle de PER__ contenant la rubrique sur laquelle nous allons effectuer la recherche. Ici nous allons sur le modèle PER_Tech. Dès l'arrivée sur le modèle, on se met en mode Recherche et on défini notre critère de recherche : la rubrique "PER__::Nom" doit contenir la valeur de la variable. ATTENTION : on a bien quitté le contexte INS, et la rubrique sur laquelle est faite la recherche n'est plus ins_PER__Eleves::Nom, mais maintenant PER__::Nom, vu le contexte du modèle PER_Tech. Dès que le critère de recherche est défini, on exécute la requête. 2 remarques :
Les 3 casOn analyse les 3 cas par les commandes :
1. Aucun enregistrement trouvé C'est le contrôle d'erreur : si aucun enregistrement n'est trouvé, quelle qu'en soit la cause, l'erreur n'est pas nulle et on peut en capter la valeur. On se contente ici de contrôler que le code d'erreur est ≠ 0. Si tel est le cas, on retourne sur le modèle de départ, par la commande Activer modèle [Modèle d'origine] : il n'est pas nécessaire de préciser le modèle du départ du script. On arrête ensuite le script par la commande Fin de script (sinon, il continue...) 2. Un seul enregistrement trouvé Dans ce cas on active le modèle PER_Fiche, comme prévu. 3. Plusieurs enregistrements trouvés Dans ce cas, c'est le modèle PER_Liste qui est activé Remarques sur l'utilisation du "SINON SI" et "SINON"Nous commençons par un SI qui vérifie si une erreur est apparue. S'il n'y a pas d'erreur (dernière erreur = 0), le script passe à la Fin de Si ou au prochain "Sinon" situé avant la "Fin de Si". Mais il nous reste deux cas de figure à tester, donc finalement une autre condition, d'où le Sinon si. Si cette nouvelle condition n'est pas vérifiée non plus, il nous reste donc uniquement la troisième hypothèse. Mais cette hypothèse ne peut être située après le "Fin de Si", car elle serait exécutée à tous les coups. D'où l'intérêt du simple "SINON", qui nous permet en quelque sorte de dire au script "tu vérifies tout, et si rien n'est vérifié, alors tu fais ça". Fin du scriptOn remarquera que notre script se termine juste après la fin de si. En fait, il n'est pas nécessaire d'indiquer à ScriptMaker que le script est terminé. S'il ne rencontre plus d'instructions, il s'arrête tout seul. Par contre, si un résultat doit être envoyé après l'exécution du script, l'instruction Fins de Script sera utilisée. Nous sommes passés par le modèle PER_Tech, en présisant bien qu'il ne fallait pas que le script se termine sur ce modèle. En effet, il apparaitrait alors aux yeux de l'utilisateur, qui n'est jamais censé voir ce modèle.
Ouf, tout va bien. BoutonOn place un bouton sur le modèle INS_Fiche, à côté de la rubrique ins_PER__Eleves::Nom, et on y "accroche" le script :  RemarquesBien entendu, le contrôle d'erreur est ici limité aux enregistrements trouvés et le but recherché est d'illustrer la gestion d'un résultat de recherche. Il est évident que le contrôle d'erreur est ici incomplet et devrait envisager l'ensemble des erreurs possibles. Citons par exemple :
Voilà, un script de plus dans notre fichier. C'est le moment de le tester. Et ce sera aussi l'occasion de constater quelques points importants sur la notion de tables... Dans notre fichier à jour, placez vous sur la table PER_Liste. On affiche tous les enregistrements (menu "Enregistrements => afficher tous les enregistrements" ou pomme/Ctrl J). La zone de contrôle à gauche nous indique bien un total de 87 enregistrements. Plaçons-nous maintenant sur le modèle INS_Liste et de la même manière, nous affichons tous les enregistrements (63). Première remarque, nous n'avons pas le même nombre. Rien de plus normal, nous avons 87 personnes enregistrées (table PER__) mais nous n'avons procédé qu'à 63 inscriptions (table INS__). Nos enregistrements sont classés par ordre de saisie. Pas besoin de faire un tri pour le moment, nous nous plaçons par contre sur la ligne de l'élève Al Bibaque (notre 9ème enregistrement de la table INS_Liste).  Et nous passons en mode fiche... La zone de gauche comporte toujours nos 63 enregistrements. Si nous retournons maintenant sur notre modèle PER_LIste, nous avons toujours 87 enregistrements trouvés. Depuis notre modèle INS_Fiche, exécutons notre script de recherche des noms. Nous trouvons un deuxième élève, son frère Yul. Nous sommes sur le modèle PER_Liste et nous avons maintenant 2 enregistrements trouvés.  Si nous allons à nouveau sur notre modèle INS_Liste (rappelez-vous que la navigation se fait par les boutons du haut), nous avons toujours nos 63 enregistrements. Nous avons modifié le jeu d'enregistrements trouvés de PER, pas de INS. Les tables sont, en quelque sorte, indépendantes. C'est une source de confusion classique, lorsqu'on se trompe de contexte par exemple. La recherche que nous venons d'effectuer a porté sur la table PER. Nous avions quitté le contexte INS, qui donc n'a pas été modifié. Quatre leçons à tirer de ce constat :
|