Category: Technique

  • FileMaker 14 : contrôle des fins de lignes LF et CRLF

    FileMaker 14 : contrôle des fins de lignes LF et CRLF

    Mise à jour : FileMaker 16 rend désormais la technique expliquée ci-dessous inutile. Voici une technique la remplaçant.

     

    Pour qui ne connait pas FileMaker, c’est assez difficile à croire, et pour nous qui le connaissons bien, assez difficile à avouer, mais comme toutes les plateformes, FileMaker a ses faiblesses.

    Il y en a une qui remonte aux premières versions de FileMaker (soit juste après l’invention du biface), et qui nous empêche de contrôler les fins de lignes dans un fichier texte exporté par FileMaker.
    C’est peut-être un détail pour vous, mais pour ceux qui doivent travailler dans des environnements hétérogènes Mac/Windows ça veut dire beaucoup. Et plus encore si ces fichiers texte sont “avalés” par des systèmes d’exploitation plus rudimentaires tels que ceux embarqués dans, par exemple, des machines de laboratoire ou des robots (un cas classique : on peut commander ces machines en leur déposant un fichier texte quelque part, mais encore faut-il que ce fichier soit formaté exactement comme il faut).

    Peut-être avez-vous déjà fait l’expérience d’exporter un fichier texte depuis FileMaker sur Mac, même en prenant soin de choisir l’option ANSI (Windows) comme format, et en l’ouvrant avec le Bloc-notes de Windows, vous avez constaté que les retours à la ligne étaient absents? (en fait ils n’étaient pas absents, mais Windows ne comprend pas qu’il s’agit d’un retour à la ligne). Ceci dit, bien des logiciels sous Windows sont suffisamment bien pensés pour interpréter le CR comme une fin de ligne.

    Ceci est dû à une longue querelle entre Apple-Montaigu et Windows-Capulet (à moins que ce ne soit l’inverse)
    UNIX utilise le “Line Feed”, appelé LF Char (10)
    Le Mac (qui a toujours raison, car il est le plus beau) utilise le retour chariot (CR pour carriage return), ou Char (13). C’est aussi ce que FileMaker utilise en interne et représente par le signe ¶.
    Windows (qui est fait pour ceux qui s’y connaissent, et donc a encore plus raison) utilise une combinaison des deux : CRLF. Ceinture et bretelles.

    Il n’y avait donc pas de moyen “natif” jusqu’ici de contrôler cette fin de ligne. On pouvait toutefois utiliser une commande externe (AppleScript, shell, batch…) ou un plugin, mais ça semblait être un marteau pour écraser une mouche… et ça n’était pas compatible FileMaker Go et WebDirect (oui, je sais, on trouve toujours le moyen, mais avec des bidouilles anormales).

    On finissait par se dire que personne chez FileMaker ne se pencherait sur le problème… et on avait raison !
    Mais, au détour d’une modification apportée par FileMaker 14, nous avons un moyen de parvenir à nos fins.

    Attention toutefois, si grâce à cette technique on peut contrôler le LF ou le CRLF, il est paradoxalement impossible de contrôler le CR. Un export natif vous permet malgré tout toujours de créer un fichier CR (et puis honnêtement, le Mac étant le seul à l’utiliser, et étant par ailleurs suffisamment bien conçu pour s’accomoder très bien d’un LF ou d’un CRLF, il n’est pas crucial d’exporter en CR).
    Si vous n’avez rien compris, c’est que j’ai mal expliqué. Laissez-moi une deuxième chance en regardant la vidéo et une troisième en téléchargeant le fichier 🙂
    Si vous aimez, n’hésitez pas à mettre un petit commentaire ci-dessous.

    Note : dans cette vidéo, nous utilisons un traitement de texte TextWrangler gratuit, que vous pouvez trouver ici

    Téléchargez le fichier de démo ici : Fichier 1MT_EndOfLine.fmp12

  • FileMaker 13 : alternative aux menus locaux

    Sur les modèles FileMaker, les menus locaux sont particulièrement importants dans le cadre d’une base de données relationnelle.

    En effet, ils sont le seul contrôle qui permet de sélectionner une valeur (ID) tout en affichant un libellé (key).

    Malheureusement, les différentes plateformes gèrent plus ou moins bien ces contrôles. Ainsi, sur Mac OS X, il n’est pas possible de dérouler ces menus autrement qu’à la souris (il n’existe aucun moyen de scripter l’ouverture d’un menu local) [Mise à jour : depuis FileMaker 15, il est possible d’ouvrir un menu déroulant avec la touche espace]. Sous Windows, c’est le défilement à l’intérieur du menu qui n’est pas possible au clavier, rendant le menu local inefficace en cas de longue liste de valeurs.

    Déjà avec FileMaker 12 et la fonction ExecuterSQL, il était possible de remplacer les menus locaux par des listes déroulantes, mais l’affichage de la valeur (ID) remplaçait celui du libellé.

    En utilisant une nouvelle fonctionnalité de FileMaker 13, le décalage de ligne de base, il est possible d’arriver à une solution presque satisfaisante.

    Voici donc un fichier de technique illustrant ceci.

    Téléchargez le fichier de démo ici : Fichier 1MT_AlternativePopupMenus.fmp12

  • FileMaker 13 tip: Horizontal portals

    It’s been a while since the initial release of FileMaker Go. In the meantime, iPhone displays have higher longer, but not wider… Didn’t your ever wish to scroll through records horizontally rather than vertically?

    This FileMaker 13 demo file quite does the trick!

    Download

  • Technique FileMaker 13 : Tables externes horizontales

    Technique FileMaker 13 : Tables externes horizontales

    Depuis la sortie de FileMaker Go, la longueur des écrans de l’iPhone a grandi, mais la largeur n’a pas évolué.

    N’avez-vous jamais regretté de ne pouvoir défiler dans les enregistrement horizontalement plutôt que verticalement ?
    Malheureusement, les tables externes natives ne permettent pas cela.

    Cette technique utilise des fonctions de FileMaker 13 et rend désormais cela possible.

    Téléchargez le fichier de démo ici : Fichier 1MT_HorizontalPortal.fmp12

  • Publication Web XML

    Publication Web XML

    XML, la ressource méconnue de FileMaker Server

    Suite à la publication de notre technique open source et gratuite FMSDIFM (FileMaker Server, Do It For Me), et aux demandes d’assistance que nous avons reçues pour l’intégrer dans des solutions existantes, nous avons pu constater que la capacité de FileMaker Server de publier des données via l’interface XML était largement méconnue.

    Voici donc une video et un fichier à installer sur votre FileMaker Server qui vous aideront à appréhender les possibilités fantastiques offertes par la publication web xml. (XML Web Publishing)

    Téléchargez le fichier de démo ici : Fichier 1MT_XML_WebPublishin.fmp12

  • FMSDIFM en Open Source à la conférence de Berlin

    FMSDIFM en Open Source à la conférence de Berlin

    Comme annoncé il y a quelques mois, la version open source, gratuite, et facile à implémenter de FMSDIFM (FileMaker Server, Do It For Me) a été présentée aujourd’hui à la conférence Pause On Error de Berlin.

    FMSDIFM est une technique qui permet de confier au serveur les tâches lourdes et lentes à exécuter qui étaient d’ordinaire exécutées par les clients FileMaker Pro/Go.

    Vous trouverez plus de détails ainsi qu’un lien de téléchargement ici. Suivez le produit sur Twitter avec le hashtag #FMSDIFM, ou sur notre page FaceBook

  • La logique booléenne

    La logique booléenne

    Parfois utilisée sans le savoir, parfois mal maîtrisée, la logique booléenne permet de simplifier grandement le développement de solutions FileMaker.

    Bien que FileMaker ne propose pas de type de données booléen, un certains nombre de traitements reposent sur la logique booléenne. Dès lors, non seulement la compréhension de cette logique est importante pour le développement d’une solution, mais aussi, elle permet de mieux appréhender certains aspects de FileMaker, tels que les fonctions logiques, les opérateurs, la sécurité, le formatage conditionnel et tant d’autres.

    Dans cette vidéo, nous verrons comment exploiter cette logique booléenne dans plusieurs exemples.

    Télécharger

  • Tables externes hiérarchiques avec ExecuterSQL

    Tables externes hiérarchiques avec ExecuterSQL

    Il y a peu, Doug West, Excelisys, publiait une technique intéressante et simplifiée de gestion de tables externes hiérarchiques.

    Néanmoins, elle repose toujours sur un modèle de données qui rend difficile les manipulations de l’arborescence.

    Voici une alternative, qui utilise la fonction ExecuterSQL de FileMaker12. (Vidéo en Anglais)

    Télécharger

  • Self (Contenu), la fonction cognitive de FileMaker

    Self (Contenu), la fonction cognitive de FileMaker

    L’expérience de la formation FileMaker m’a entre autre appris que parmi les nombreuses fonctions de calcul de FileMaker, il en est une qu’il est toujours difficile d’expliquer à une personne n’ayant pas de notions de programmation orientée objet.

    Apparue avec la version 9 de FileMaker, la fonction Contenu (Self en anglais), est classée dans les fonctions logiques. C’est une fonction tellement particulière qu’elle a droit à un message d’erreur particulier quand vous l’utilisez dans certaines formules. Toutes les autres fonctions de calcul peuvent être utilisées dans n’importe quelle formule, mais pas celle-ci. Dans la plupart des cas, un message apparaît vous indiquant que vous ne pouvez utiliser cette fonction.

    self error message

    De plus, elle ne prend pas de paramètre, ce qui est assez rare (mais pas unique ! Alea par exemple n’en prend pas non plus)

    Au caractère abstrait de cette fonction s’ajoute pour les francophones une difficulté de traduction. Self veut dire “soi-même”, mais on peut en Anglais parler du self d’un tiers (c’est d’ailleurs un concept de psychanalyse inventé par Winnicott).freud

    Plus loin dans l’Histoire de la psychanalyse, Freud parlait du “Moi” (concept très différent mais autre traduction possible de la fonction de calcul – juste pour redescendre un peu. Entre parenthèses le “Moi” freudien est déjà une traduction très controversée de “Ich”, qui signifie littéralement “Je”, qui pour le coup serait une traduction inappropriée de la fonction)

    Beaucoup de détours me direz-vous ? Pas tant que ça je crois. Car ces différents concepts (que je ne détaille pas ici mais que rien ne vous empêche d’explorer en suivant les liens) permettent d’approcher la fonction Contenu et ses évolutions. Car oui, vous avez bien lu, à cette complexité conceptuelle s’ajoutent les évolutions de cette fonction, qui est devenu beaucoup plus puissante au fil des versions.

    FileMaker 9 : Une référence au contenu

    Telle qu’apparue avec FileMaker 9, on peut dire que la traduction française (Contenu) était plus pertinente que la VO (Self). En effet, la fonctionnalité se résumait à peu de chose.

    Il n’était alors possible d’utiliser cette fonction que dans deux situations :

    • un calcul auto-entré dans les options d’entrée automatique d’une rubrique
    • dans la définition du formatage conditionnel
    • il est également possible d’utiliser Contenu dans une rubrique calcul, mais très honnêtement nous nous lancerions ici dans une explication à côté de laquelle la psychanalyse serait futile.

    Je vous passe le détail de deux bugs qui m’avaient fort énervé (et qui n’ont pas été réglés avec les mises à jour de FileMaker 9 mais seulement en FileMaker 10), mais en gros ils rendaient l’utilisation de Contenu impossible, et dans bien des cas celle du formatage conditionnel également. (Pour les historiens que ça intéresse vraiment, je suis prêt à développer mais le simple fait d’évoquer ces bugs titille mon ulcère)

    Donc, si tout avait bien marché, qu’aurions-nous pu faire avec ça dès la version 9 ?

    • Modifier une donnée qui vient d’être entrée par l’utilisateur ou lors d’un import. Par exemple on pouvait supprimer les espaces avant et après le texte ainsi : Supprespaces ( Contenu ). Rien de neuf sous le soleil, mais cela permettait d’utiliser la même formule pour nettoyer plusieurs rubriques, alors qu’auparavant ce résultat n’aurait été obtenu que par la formule : Supprespaces ( nomDeLaRubrique ), qui aurait donc été différente d’une rubrique à l’autre.
    • Se référer au contenu d’une rubrique (ou d’un objet de modèle) pour le formater. Ainsi on peut, par exemple, colorer une rubrique différemment en fonction de la valeur qu’elle contient. Là encore, l’intérêt est de pouvoir utiliser la même formule pour le formatage de différents objets de modèle. Il y a là un second intérêt qui est que tout objet contenant quelque chose peut éventuellement être formaté en fonction. Petit bémol, seuls peu d’objets peuvent alors être formatés de la sorte. Seuls les éléments de texte et les rubriques sont concernés. Depuis FileMaker 12, les onglets peuvent également être formatés conditionnellement en fonction de leur libellé.

    Pour comprendre ces utilisations, il faut se demander qui exécute le calcul, ou plutôt qui demande à l’exécuter. Dans le cas de l’auto-entrée, c’est la rubrique qui demande l’évaluation de la formule afin de définir son propre résultat, Contenu retourne donc le contenu de la rubrique avant l’évaluation du calcul. (Si la rubrique contient 1, alors Contenu + 1 = 2). De même, si l’objet de modèle contient la date du jour (indépendamment de la nature de cet objet, un symbole de modèle, une rubrique de fusion, une rubrique classique…), la formule ObtenirDate ( Contenu )) > Dossier ::dateLimite permettra de formater l’objet si la date limite du dossier est dépassée.

    Note : il ne faut pas confondre Contenu et Obtenir ( ContenuRubriqueActive ). Cette dernière fonction renvoie exclusivement le contenu de la rubrique dans laquelle est le curseur, il n’y a pas d’auto-référence induite dans cette fonction.

    FileMaker 10 : un pointeur multiple

    Avec FileMaker 10, outre le fait que les deux principaux bugs (ceux de l’ulcère) ont été réglés, la fonction a gagné en puissance. Sa traduction (Contenu) est devenue désuète, même si elle n’a pas changé pour ne pas dérouter les quelques utilisateurs qui ne l’étaient pas encore.

    Self est désormais porteuse de deux pointeurs. L’un au contenu, comme avant, et l’autre à la rubrique en tant qu’élément de structure de la base de données. (Si vous n’avez rien compris à cette phrase, c’est normal. Moi-même, je ne suis pas très sûr… mais nous sommes en psychanalyse, souvenez-vous…)

    Il faut ici rappeler que FileMaker 10 a également apporté deux fonctionnalités majeures et complémentaires : Définir Rubrique par nom (action de script), et ObtenirNomRubrique (fonction de calcul). Vous trouverez de nombreux exemples d’utilisation dans cet excellent article.

    Or, si l’on s’amuse à créer une fonction personnalisée (FileMaker Pro Advanced requis) telle que Moi ( _parametre ), avec la formule suivante : ObtenirNomRubrique ( _parametre ), et que l’on utilise cette fonction dans la formule d’un calcul auto-entré d’une rubrique :

    Moi ( Contenu )

    Que croyez-vous qu’on obtiendra ?

    La logique vue précédemment voudrait que Contenu pointe vers le contenu de la rubrique, et le transmette à la fonction qui, essayant d’extraire un nom de rubrique à partir d’un paramètre n’ayant rien à voir avec un nom de rubrique, retournerait un beau point d’interrogation.

    Concrètement, si une rubrique MaTable ::MaRubrique contient

    “Ça va ? vous suivez toujours ?”

    et que la formule d’auto-entrée est

    Moi ( Contenu )

    on aurait pu penser, puisque la fonction s’appelle contenu, que la fonction Moi évaluerait le calcul :

    ObtenirNomRubrique ( “Ça va ? vous suivez toujours ?” )

    et qu’elle n’aurait pas su répondre à cette question, car il n’existe pas de rubrique de ce nom.

    Or -c’est là que ça devient subtil- le résultat de la fonction sera bien :

    MaTable ::MaRubrique

    En utilisant la fonction Contenu comme paramètre de la fonction personnalisée, on envoie en fait deux informations de natures différentes : le contenu de la rubrique et l’identité de la rubrique. Selon le traitement effectué ensuite par la fonction personnalisée, l’une ou l’autre de ces informations sera traitée.

    En réalité, c’est la fonction ObtenirNomRubrique qui est ici “magique” puisqu’elle traite une autre information que celle qu’on croyait passer. Mais il est remarquable que Self puisse passer cette information.

    FileMaker 13 : de nouvelles possibilités

    Un petit saut dans le futur, ou plutôt dans mes rêves (c’est une expression, il serait curieux de commencer un article en parlant de psychanalyse et de le terminer en rêvant de FileMaker 13 !)

    Self est donc capable de représenter des entités différentes (une rubrique, un objet de modèle), et de référencer des informations de natures différentes (une valeur, un élément de structure de la base de données). Autrement dit cette fonction a de sérieux atouts qui pourraient régler des problèmes que nous rencontrons quand nous développons nos solutions FileMaker.

    • référence de l’objet de modèle. A ce jour, il n’est toujours pas possible de connaître le nom de l’objet de modèle ayant déclenché un script, soit qu’il s’agisse d’un déclencheur ou simplement d’un bouton. Si on pouvait passer Self en paramètre de script et dans le script connaître tout de l’objet qui a déclenché le script, ce serait un grand progrès…
    • référence de la variable ou de la rubrique que l’on est en train de définir. Par exemple Définir variable [ $i ; Self + 1 ] au lieu de [ $i ; $i + 1 ] ou Définir rubrique [ Commissions ::liste ; Liste ( Self ; “Artichauts” )] au lieu de [ Commissions ::liste ; Liste ( Commissions ::liste ; “Artichauts” )]

    C’est tout pour aujourd’hui, notre séance s’arrête là. Ça n’est pas remboursé. 🙂

  • Liens non indexés

    Liens non indexés

    Voici une très courte vidéo qui répond à une question fréquemment posée sur les forums FileMaker.

    La problématique est :

    “J’ai un calcul que je voudrais utiliser comme critère d’un lien, mais le lien ne fonctionne pas car le calcul est non mémorisé.”

    Or, s’il est connu qu’une rubrique non indexable (dont les calculs non mémorisés) ne peuvent être utilisés comme destination d’un lien, leur faculté d’être utilisés comme source de ce lien est souvent sous-estimée.

    Dans cette vidéo, nous montrons comment établir un lien comme celui-ci.

    L’exemple est le suivant :

    Nous cherchons à afficher une table externe des employés actifs (en fonction de la date actuelle). Comme l’utilisation de la date actuelle sous-entend un calcul non mémorisé, on ne peut a priori pas utiliser ce critère dans le lien.

    Vous retrouverez cette technique et d’autres sur le graphique des liens dans cette vidéo de 1-more-tube.

  • Double clic

    Double clic

    Une fonction de calcul cachée de FileMaker 12 déchaîne les passions sur le web. Elle permet de capter le timestamp actuel en milisecondes, et en UTC (GMT) !

    Dans cette vidéo, nous aborderons quelques possibilités d’utilisation et livrerons un exemple avec -enfin !- une technique de double clic qui fonctionne.

    Télécharger

    Mise à jour : FileMaker 13 vient d’officialiser cette fonction, nommée Obtenir ( HeureActuelleUTCMillisecondes )

  • Interactions avec le WebViewer

    Interactions avec le WebViewer

    La nouveauté la plus marquante de FileMaker 12 est a priori le nouveau rendu des modèles.

    Il est vrai que l’interface des solutions FileMaker commençait à dater un peu, et il est certain que ces nouveaux modèles permettent de concevoir des intefaces plus modernes.

    Néanmoins, la grande nouveauté en termes d’interface ne réside peut-être pas là…

    Le protocole d’URL fmp :// permet désormais d’exploiter des interactions entre le webviewer et vos données.

    Combiné à des langages web modernes tels que jQuery et CSS, ce protocole permet à votre solution de s’habiller d’une interface élégante, moderne et efficace.

    Vous pouvez gérer le drag’n’drop et les gestes en général (oui, les gestes ! y compris sur FileMaker Go !), présenter des tableaux dont vous contrôlez l’aspect (titre des colonnes, colonnes redimensionnables…), des tirettes (sliders), ou pourquoi pas un agenda.

    Les possibilités sont vertigineuses.

  • Masquer des objets de modèle

    Masquer des objets de modèle

    Contrôle des onglets par script

    FileMaker 12 permet (enfin !) d’afficher/masquer des onglets en les activant par script, sans devoir recourir à des stratagèmes (ou “bidouilles”) pour empêcher l’utilisateur d’activer un autre onglet, et sans scripts compliqués pour revenir à l’onglet précédemment sélectionné.

    Voici donc une vidéo explicative, et un petit fichier avec une technique toute simple à mettre en œuvre dans votre propre solution.

    Télécharger

  • Hide layout objects

    Hide layout objects

    Script controlled tab switching

    Finally! FileMaker 12 provides a clean method to control tab switching by script and therefore to show/hide layout objects conditionnally, without requiring tricks like overlappling objects or complex scripts to reset the original tab.

    Here is a video and a very simple technique file, extremely easy to reproduce in your own solution.

    Download

     

  • FileMaker 12 – Video – FMSDIFM

    FileMaker 12 – Video – FMSDIFM

    Grâce à FMSDIFM de 1-more-thing, (FileMaker Server, Do It For Me), FileMaker devient une vraie solution performante dans le cloud.

    Au-delà des nouveautés mises en avant par FileMaker lors de la sortie de FileMaker 12, voici LA révolution dans la conception de solutions FileMaker.

    Comme vous le verrez, il est désormais possible de déléguer les tâches gourmandes en ressources à FileMaker Server, permettant des gains de performances prodigieux. le consultant FileMaker peut ainsi proposer des vraies solutions sur le cloud, avec les avantages d’une interface FileMaker, et des performances telles qu’on les connaît quand on travaille sur un poste local. Même avec FileMaker Go !

    D’autre part, cette technologie maison permet de développer des scripts décontextualisés (finis, les changements de modèles, ouvertures de fenêtres, mémorisation des onglets…). Cela permet non seulement un gain de performances encore accru, mais élimine les effets inesthétiques des ouvertures de fenêtres sous iOS ou sous Windows.

    Le meilleur dans tout ça : FMSDIFM (FileMaker Server, Do It For Me) est offert à tous nos clients en hébergement !

  • Fonctions fm.field

    Fonctions fm.field

    FileMaker 10 a apporté une nouvelle fonction (ObtenirNomRubrique/GetFieldName) et une nouvelle action de script (Définir rubrique par nom/Set field by name), qui permettent au développeur de s’affranchir du nom des rubriques et de développer de manière beaucoup plus dynamique.

    Problème : il n’est pas toujours simple de calculer le nom de la rubrique cible (Définir rubrique par nom), ou d’extraire un élément du nom de la rubrique retourné par ObtenirNomRubrique.

    En effet, ces fonctions travaillent sur le nom complet de la rubrique : table ::rubrique, alors que les fonctions Obtenir(NomRubriqueActive) et Obtenir(NomTableRubriqueActive) renvoient respectivement le nom de la table et le nom de la rubrique, mais à condition que la rubrique ait été activée auparavant (ce qui implique notamment qu’elle soit présente sur le modèle courant)

    Voici donc un ensemble de fonctions qui permettent facilement d’extraire (fm.field.get) ou de composer (fm.field.set) le nom de la rubrique, y compris en tenant compte des multivaluées.

    fmfunctions

  • Fonctions SQL

    Fonctions SQL

    Avec la sortie de FileMaker 12, la fonction ExecuterSQL permet au développeur FileMaker de formuler des requêtes complexes beaucoup plus facilement qu’avec le graphique des liens et des calculs.

    Un autre -immense- avantage des requêtes SQL est qu’elle sont exécutées indépendamment du contexte. Il n’est donc plus nécessaire, dans un script, de multiplier les changements de modèles ou ouvertures de fenêtres, coûteux en temps de chargement et inesthétiques en FileMaker Go ou sous Windows.

    Et puis, il y a cet immense avantage par rapport aux plugins : la fonction est compatible avec FileMaker Go !

    Tout est pour le mieux donc, mais il existe des limites à cette “magie”.

    • la fonction ExecuterSQL est limitée à la requête SELECT, c’est-à-dire que l’on peut lire, mais pas écrire dans la base de données. Cette limite est d’autant moins compréhensible que les plugins ou des clients ODBC sont autorisés à effectuer ces opérations via l’interface sql.
    • dans la même veine, on peut regretter l’absence de paramètre nous permettant de préciser à quel fichier FileMaker on s’adresse. Les plugins, ainsi d’ailleurs que les fonctions de conception de FileMaker, peuvent interroger un autre fichier que le fichier actif (à condition qu’il soit ouvert), sans même que le fichier soit référencé par le fichier actif. Ceci est très pratique car cela permet d’éviter des dépendances inutiles. Intéressant par exemple quand on a un fichier embarqué sur un iPhone qui doit régulièrement synchroniser ses informations avec un fichier sur serveur, sans pour autant que l’on souhaite une connexion permanente. Cette absence est d’autant pus surprenante que le nouveau support du protocole URL nous donne une nouvelle arme pour cette communication entre fichiers.
    • l’interface SQL travaille sur son propre système d’indexation, ce qui veut dire que la première requête sur une rubrique d’une table comportant beaucoup d’enregistrements va potentiellement prendre plusieurs secondes là où un lien FileMaker aurait donné un résultat immédiat. Fort heureusement, une fois cette première requête effectuée, les opérations seront très rapides. Etrangement, on voit là encore une différence dans les performances, au très net avantage des plugins, notamment du meilleur d’entre eux, DoSQL de myFMbutler.
    • le pendant de l’indépendance du contexte, c’est que… ExecuterSQL ne peut pas du tout tirer parti du contexte. On ne peut pas influencer le résultat d’une requête avec le graphique des liens. Mais est-ce vraiment une limite ?
    • cela nous mène à la quatrième limite, la plus importante sans doute, parce qu’elle se situe “entre la chaise et le clavier” : la plupart des utilisateurs ou développeurs FileMaker n’ont pas l’habitude de formuler des requêtes SQL. La logique du graphique des liens et des calculs nous a “formatés” et il ne nous est pas forcément évident de tirer profit.

    C’est sur cette dernière limite que nous nous penchons aujourd’hui, parce qu’elle semble être la seule sur laquelle nous puissions influencer à court terme.

    Car fort heureusement, nous sommes humains (enfin, je ne peux le garantir pour vous, mais en ce qui me concerne, c’est une certitude). Or homo sapiens est très doué pour l’apprentissage, et en particulier avec un sujet aussi “simple” que SQL. Sérieusement, les rudiments de SQL (ceux que l’on utilise pour 95% des requêtes) s’apprennent en quelques minutes. Personnellement, quand je sèche, je regarde ici.

    Il existe aussi de nombreux forums dédiés à SQL, où certains ont déjà publié des requêtes compliquées. Ainsi, si je n’ai aucune idée de la manière de sélectionner les factures de 2009 à 2012, regroupées par mois et classée par montant décroissant… je pose ma question littéralement sur Google. Si j’ai la chance de parler l’anglais, je la pose en Anglais pour plus de réponses. Et il est rare que je ne trouve pas une réponse toute faite ou approchant sensiblement.

    Mais puisqu’il faut s’y mettre, autant essayer un peu par soi-même. Et vous le verrez, on arrive très vite à quelque chose.

    Seulement, au bout de quelques requêtes plus ou moins péniblement formulées, vous vous rendrez compte que :

    • le nom des rubriques et des tables est “hard-codé” dans la requête. SQL nous ferait donc perdre l’avantage immense de FileMaker de ne pas avoir à se soucier du nommage ?
    • vous utilisez exactement la même requête plusieurs fois, pour des rubriques et des tables différentes. Typiquement, c’est celle-ci : “donne moi la liste du (des) enregistrement(s) dans la table X dans lequel (lesquels) la rubrique Y a le contenu Z. Plus concrètement : “donne-moi tous les ID de mes pots de confiture dont le fruit est Abricot.” Ou au contraire, “donne-moi le fruit du pot de confiture dont l’ID est 348”

    Pour pallier à ces deux “problèmes”, qui encore une fois ne viennent pas de la technique mais de nous-mêmes, j’ai publié une fonction personnalisée qui devrait nous aider à nous lancer.

    Voici comment l’utiliser :

    sql.match ( _requestedFieldName ; _matchFieldName ; _match )

    • _requestedFieldName : le nom complet de la rubrique que l’on souhaite obtenir (respectivement potDeConfiture ::ID et potDeConfiture ::fruit dans les exemples précédents)
    • _matchFieldName : le nom comple de la rubrique à tester (l’autre rubrique)
    • _match : le critère d’égalité (“abricot” ou 348)

    Le plus simple est de l’utiliser en combinaison avec la fonction ObtenirNomRubrique, afin de ne pas dépendre du nommage.

    Exemple : sql.match( ObtenirNomRubrique ( PotDeConfiture ::ID ) ; ObtenirNomRubrique ( PotDeConfiture ::fruit ) ; "Abricot" )

    renverra une liste des ID (séparés par des retours chariot) des Pots de confiture d’abricot

    Ah ! un dernier détail. Afin de pouvoir observer la requête effectivement exécutée, une variable $sql.match.query sera déclarée.

    Nom de la table Et puis, je ne résiste pas au plaisir de vous signaler cette autre fonction fm.basetable.name. Ceci résout un manque que je trouvais patent depuis de nombreuses années : la possibilité de connaître par calcul le nom de la table représentée par une occurrence de table.

    Alors ? on s’y met ? Joyeux SQL à tous !

  • FileMaker 11 – Video – Liens snapshot

    FileMaker 11 – Video – Liens snapshot

    Dans cette nouvelle vidéo gratuite, nous abordons une des nouveautés les plus utiles de FileMaker 11 : les liens snapshot.

    Un snapshot permet de mémoriser un ensemble d’enregistrements dans une vue particulière (modèle, mode d’affichage, tri…)

    Découvrez comment les liens snapshots peuvent vous être utiles.

     

  • FileMaker 11 – Video – Déclencheurs

    FileMaker 11 – Video – Déclencheurs

    Dans ce troisième épisode gratuit sur FileMaker 11, nous abordons les déclencheurs.

    Les nouveaux déclencheurs de la 11 sont :

    • SurValidationObjet (Pre)
    • SurModificationObjet (Drag’n Drop) (Post)
    • SurSortieModele (Pre)
    • SurChangementVue (Post)

    Comme toujours, n’hésitez pas à laisser vos commentaires, surtout s’ils sont positifs ! 😉

  • FileMaker 11 – Video – Fondamentaux

    FileMaker 11 – Video – Fondamentaux

    Voici la deuxième vidéo de notre série consacrée à FileMaker 11.

    Pendant près d’une demi-heure, nous examinons l’impact de la nouvelle architecture “Cocoa” de la version Mac, nous observons les plus importants changements dans l’interface, mais nous abordons aussi certains détails pour lesquels il n’existe pas de documentation.

    Regardez cette video pour profiter à plein de FileMaker 11.

    N’hésitez pas à laisser un commentaire ci-dessous !