voilà déjà quelques mois que nous avons assisté à la conférence FileMaker de Montréal. Durant cette fin de semaine, on m'a demandé d'élaborer sur ma technique utilisée afin de créer des triggers directement sur un ou plusieurs champs.
L'exemple que je démontre aujourd'hui a servi (et sert toujours, d'ailleurs!) à établir un historique de certaines informations qui sont changées régulièrement dans le processus chez Décalcorama.
Voici donc à quoi ressemble le graph des liens pour cette technique
Screen shot 2012-07-09 at 1.35.16 PM.png 18,19K
2 Nombre de téléchargements Cette technique nécessite le plugin "SQLRunner", puisque FileMaker ne nous a pas donné encore accès aux fonctions de modifications des données par SQL (je retire des privilèges à mes enfants lorsqu'ils ne sont pas assez gentils, ou encore lorsque je crois qu'il ne seront pas capable de gérer ces privilèges.) Vous pouvez trouver ce plugin ici.
Le but recherché est très simple: je veux qu'à chaque fois qu'un utilisateur modifie une infos sur une série de champs bien précis un historique se crée dans une autre table. Bien sûr, je pourrais arriver au même résultat en mettant des script triggers un peu partout. Je n'aime pas ça, puisque j'ai beaucoup de layouts a gérer (200+). De plus, je ne dois jamais oublier de mettre mon script trigger lorsque j'ajoute un de ces champs dans un nouveau layout que je monte pour un usager.
Or, avec cette technique je m'assure de rendre ma solution modulaire.
Je crée une table "HistoriqueCL" et j'y inclus les champs que je veux conserver en auto-enter (un lookup peut faire aussi)
Screen shot 2012-07-09 at 1.44.11 PM.png 22,54K
0 Nombre de téléchargements Ensuite, je n'ai qu'à créer un champ global auto-enter dans la table "CL". Voici sa définition:
Evaluate( "epSQLExecute( \"INSERT INTO HistoriqueCL(ID_CL) Values(\" & Commande_Lignes::No Unique & \")\" )" ; [ // Lister ici tous les champs qui doivent trigger la création d'historique // Transport Transport_Calcul ; Transport_Service_Calcul ; Transport_Paiement_Calcul ; Transport_Type_Calcul ; DestComplet_Final ; ExpComplet_Final ; // Qte QteSaisie ; QteExped ; QteFact ; // Prix Prix_Cost_Unitaire ; Prix_Cost_Unitaire_Backup ; Prix_Detail_Unitaire ; Prix_Qt ; Prix_Transfert_Unitaire ; Prix_Vendant_Unitaire ; Prix_Vendant_Unitaire_Backup ; // Code CodeProduit_Saisie ; // Dates Date d'expédition calcul ; ] )
La fonction "Evaluate" peut être muni d'un nombre illimité de paramètres suivant le calcul. Selon l'aide de FileMaker, ces paramètres servent de trigger au calcul du Evaluate.
Ce n'est pas plus compliqué que ça !
Comment j'ai pensé à tout ça ? Le directeur de production m'appelait pour me dire: "Le client s'est plaint qu'on n'a pas envoyé à la bonne adresse. Qui a changé l'adresse du destinataire?". Je devais ensuite soit fouiller dans les backups pour espérer trouver quelque chose, soit appeler tout le monde qui était susceptible d'avoir changé les infos sur cette commande. Comme la commande avait été expédiée il y a quelques jours, plus personne ne s'en rappelait.
Je peux désormais appeler directement la personne en question et lui demander "Pourquoi as-tu changé les infos de transport le 5 Juin 2012 à 13:45:08 ?"
Bonne journée !
[OS] Ça aurait fait un beau topo pour Toulouse ! [/OS]
