DevCon96 et 4D-FORUM

Les procédures stockées et triggers

(par Dominique HERMSDORF, rapporté par Christian QUEST et Matthieu BAUDOUX).

Grâce aux proc. stockees, on peut désormais exécuter du code 4D cote serveur lorsque l'on est en arch. client/serveur.
Exécuter sur serveur fonctionne comme Nouveau process, mais le process sera crée sur le serveur et s'exécutera sur le serveur. Si on est en monoposte, Exécuter sur serveur aura le même effet que Nouveau process (ceci a été confirme par LR après l'atelier).
Exécuter sur serveur renvoie un numéro de process négatif, ce qui permet de différencier les process "locaux" (positifs) des process "serveur" (négatifs).

Bonne nouvelle cote passage de paramètres, on peut désormais passer des paramètres dans Nouveau process et Exécuter sur serveur.
Ces paramètres arriveront dans les $1, $2, etc. habituelles.
Les proc. stockees peuvent faire appel a à peu prêt tout le langage (y compris les externes). La seule chose qui semble être interdite c'est tout ce qui touche a la saisie/modif manuelle de données ("modifier sélection" par exemple).
Il y a de nouvelles instructions (qui peuvent aussi servir en monoposte) pour lire et modifier le contenu d'une variable d'un process.
LIRE VARIABLE PROCESS(num de process; var process; var locale; var2 process; var2 locale...) et FIXER VARIABLE PROCESS(num de process; var process; var locale; var2 process; var2 locale...)
Ceci permet de passer des informations d'un process a un autre (en local ou en client/serveur).
Remarque: on peut passer un tableau d'un coup si on veut ce qui sera très pratique a mon avis.

et bien d'autres choses...

(par Dominique HERMSDORF, rapporté par Christian QUEST et Matthieu BAUDOUX)

Le principe des triggers est d'avoir des règles de contrôle qui s'appliquent aux donnes a tout moment. Pour simplifier, les triggers sont une (bonne) évolution des formules fichier.
Dans 4Dv6, les formules fichiers sont donc remplacées par les "triggers".
Ils sont exécutés sur les événements suivants: ajout, modification, suppression et chargement d'une fiche.
Ils sont exécute non seulement dans les formats, mais aussi (et c'est la l'intérêt des triggers) depuis les proc, les externes et les accès 4D Open.
On peut donc mettre des règles de son choix qui seront toujours respectées (il n'y a pas de moyen de passer outre un trigger).
En client/serveur, les triggers s'exécutent sur le serveur.
Un trigger peut faire s'exécuter un autre trigger, il y a donc une notion de "niveau de trigger" et des commandes 4D pour gérer tout cela ce qui permet par exemple de traiter la suppression des fiches liées avec mise a jour d'autres fiches dans d'autres fichiers.

Un trigger ressemblera donc a un "au cas ou" prenant en compte les 4 cas précités et positionnera $0 soit a 0 si tout est OK soit a une valeur numérique qui sera considéré comme une erreur a part entière que l'on pourra de plus intercepter comme toute autre erreur 4D avec un APPELER SUR ERREUR.
Pour cela, d'autre commandes permettent d'éviter que la sélection ou la fiche courante ne soit modifiée lors d'une recherche, ainsi que de limiter une recherche.
FIXER LIMITE RECHERCHE permet d'indiquer a 4D de stopper la recherche
des qu'un certain nombre de fiche est atteint.
FIXER DESTINATION RECHERCHE permet d'envoyer le résultat de la recherche soit dans un ensemble, soit dans une variables (fiches trouvées), et ceci sans changer la sélection courante !!