Discussion :

[Jleyen]

Bonjour,

J'ai activé, pour une des mes tables, l'évènement trigger 'sur validation nouvel enregistrement'. Ce trigger appelle une méthode qui met à jour un tableau et le stocke dans un blob de la table [préférences].

Bien que cette méthode ne modifie PAS l'enregistrement courant qui est en cours de validation j'obtiens le message "L'enregistrement courant a été modifié par le trigger" "Le trigger a été interrompu".

Cette méthode effectue des recherches dans la base et durant l'exécution l'enregistrement courant est perdu. Mais avec ou sans empiler /dépiler j'obtiens toujours le message d'erreur -9938 !

L'enregistrement est bien créé et stocké , mais comment éviter ce message d'erreur ?

[ZeFiF]

question bête, ya pas un trigger sur la table param ?

sinon,
il me semble que les triggers ne contiennent pas de sélection ni ne charge l'enregistrement...

Les triggers sont exécutés sur la machine où est situé le moteur de la base de données. Si ce point est une évidence dans le cas de 4D en local, il convient de rappeler que pour 4D Server, les triggers sont exécutés sur la machine serveur (dans le process "jumeau" du process ayant déclenché le trigger) et non sur la machine cliente.
Quand un trigger est appelé, il s'exécute dans le contexte du process qui tente l'opération. Ci-dessous, ce process est appelé process appelant l'exécution du trigger.
Les éléments inclus dans ce contexte diffèrent suivant que la base est exécutée avec 4D en mode local ou avec 4D Server :
avec 4D en mode local, le trigger fonctionne avec les sélections courantes, les enregistrements courants, les statuts lecture/écriture des tables, les verrouillages d'enregistrements, etc., du process appelant.
avec 4D Server, seul le contexte de base de données du process client appelant est préservé (verrouillages d'enregistrements, statut lecture/écriture des tables...). 4D Server garantit également que l'enregistrement courant de la table du trigger est correctement positionné. Les autres éléments contextuels (sélections courantes par exemple) sont ceux du process du trigger.
Soyez prudent lorsque vous utilisez les autres objets de la base et du langage, car un trigger peut s'exécuter sur une machine différente de celle du process appelant : c'est le cas avec 4D Server !
Variables interprocess : Un trigger a accès aux variables interprocess de la machine où il est exécuté. Avec 4D Server, ce peut être une machine différente de celle du process appelant.
Variables process : Chaque trigger possède sa propre table de variables process. Un trigger n'a pas accès aux variables process du process appelant.
Variables locales : Vous pouvez utiliser des variables locales dans un trigger. Leur aire d'action est l'exécution du trigger (elles sont créées/détruites au cours de cette exécution).
Sémaphores : Un trigger peut tester ou placer des sémaphores globaux et locaux (sur la machine où il s'exécute dans ce dernier cas). Cependant, un trigger doit s'exécuter rapidement. En conséquence, utilisez plutôt des sémaphores locaux dans un trigger, sauf si vous avez une idée précise en tête.
Ensembles et sélections temporaires : Si vous utilisez un ensemble ou une sélection temporaire dans un trigger, vous travaillez alors avec ceux de la machine où les triggers s'exécutent. En client/serveur, les ensembles et sélections temporaires "process" (dont le nom ne débute ni par $ ni par <>) créés sur le client sont visibles dans un trigger.
Interface utilisateur : N'utilisez PAS d'éléments d'interface utilisateur dans un trigger (alerte, message ou dialogue). Cela signifie également que tracer le trigger dans la fenêtre du Débogueur doit être limité. Souvenez-vous que les triggers en client/serveur s'exécutent sur la machine 4D Server. Un message d'alerte affiché sur le poste serveur ne dit pas grand chose à l'utilisateur qui, lui, travaille sur sa machine cliente. Laissez le process appelant gérer l'interface utilisateur.

[Jleyen]

question bête, ya pas un trigger sur la table param ?

sinon,
il me semble que les triggers ne contiennent pas de sélection ni ne charge l'enregistrement...

Merci de ta réponse, mais … qu'est ce que la table 'Param' ?

Je précise que j'utilise (toujours) l'antique v2003 de 4D en monoposte sur MacOs.

[ZeFiF]

Pardon je voulais dire [préférences]

[Yexbe]

Bonjour,

Tu fais une recherche sur la table ou est le trigger ?
Dans ce cas, je te conseillerais d'utiliser la commande
"fixer destination recherche"

voir la doc

[Jleyen]

Oui, je fais bien une recherche sur cette table.

En fait j'essaie de tenir à jour un tableau qui stocke certaines valeurs de la table. J'utilise ces valeurs comme liens hypertextes dans 4D Write et ça marche plutôt bien. Là où le bat blesse c'est qu'il faut bien intégrer les valeurs des enregistrements nouvellement créés dans mon tableau si je veux pouvoir les exploiter immédiatement.

Le trigger 'sur sauvegarde nouvel enregistrement' semble idéal puisqu'il va s'exécuter automatiquement, que l'enregistrement soit créé par saisie ou par programmation.

Pour créer le tableau des valeurs je passe par un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TOUT SELECTIONNER([TableAuTrigger])

J'ai suivi ta suggestion en utilisant plutôt :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FIXER DESTINATION RECHERCHE(Vers ensemble;"monEnsem")

Mais ensuite il faut bien que je passe par
UTILISER ENSEMBLE("monEnsem") pour extraire ces valeurs par SELECTION VERS TABLEAU() ?

Résultat : Toujours le message d'erreur !

Bon, je crois que je vais installer cette routine dans le bouton de validation. Ca ne fait pas tout à fait la même chose mais ça suffira pour le moment.

Merci pour votre aide.

[ZeFiF]

et avec une sélection temporaire ?