Discussion :

[Magnus]

Bonjour,

Dans plusieurs écrans développés sous forms 10g, j'ai identifié des scénarios où l'exception FORM_TRIGGER_FAILURE est levée mais où l'exécution continue.
J'ai constaté ce fait aussi bien à l'exécution, qu'en débug.

Voici un exemple simplifié :

KEY-COMMIT

Code :

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

1
2
3
4
5
6
7
 
COMMIT;
IF FORM_SUCCESS THEN
	MSG_BOX('Modifications enregistrées avec succès.');
	CLEAR_FORM(NO_VALIDATE);
...
END IF;

PRE-INSERT

Code :

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

1
2
3
4
5
6
 
IF NOT CHECK_UNIQUE('PR0200', 'CH_NOM',  :PR0200.CH_NOM,
															'CH_MILL', :PR0200.CH_MILL) THEN
	MSG_BOX('Erreur. Cet enregistrement existe déjà.');
	RAISE FORM_TRIGGER_FAILURE;
END IF;

Scénario : créer un enregistrement non unique et valider.
Les triggers sont alors déclenchés dans cet ordre :
1/ key-commit
2/ pre-insert

A l'exécution, il s'affiche effectivement une boîte de dialogue stipulant "Erreur. Cet enregistrement existe déjà." MAIS le contrôle n'est pas immédiatement redonné à l'utilisateur : le reste du code s'exécute dont l'affichage de la boîte de dialogue "Modifications enregistrées avec succès."

Malgré le test sur FORM_SUCCESS, l'exécution du code n'est pas stoppée par l'exception.

Quelle explication voyez-vous à ce scénario ?
Quelle solution permettrait de bloquer l'exécution du code dans ce cas ?

Merci d'avance.

[SheikYerbouti]

Propager l'exception:

Code :

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

1
2
3
4
5
6
7
8
9
 
Begin
   ...
   Raise Form_Trigger_Failure ;
   ...
Exception
   When Form_Trigger Failure Then
      Raise ;
End;

[Magnus]

Salut Sheikyerbouti,

J'ai déjà eu cette idée : j'ai modifié le trigger KEY-COMMIT de la sorte :

Code :

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

1
2
3
4
5
6
7
8
9
10
BEGIN
	COMMIT;
EXCEPTION WHEN FORM_TRIGGER_FAILURE THEN
	RAISE;
END;
IF FORM_SUCCESS THEN
	MSG_BOX('Modifications enregistrées avec succès.');
	CLEAR_FORM(NO_VALIDATE);
...
END IF;

Malheureusement à l'exécution cela ne change rien : l'exécution n'est jamais stoppée et en particulier le 2ème boîte de dialogue est affichée !

Mes collègues affirment que c'est une anomalie de forms qui existait déjà lors de la version 6i avec le trigger KEY-COMMIT.
Leur alternative est complexe donc je préfèrerai simplifier cette gestion.

Une autre idée ?

[McM]

marche pô ta solution.
Bloc simple

PRE INSERT

Code :

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

1
2
3
4
5
6
7
8
BEGIN
	MESSAGE('PRE INS ');
	message(' ');
	RAISE FORM_TRIGGER_FAILURE;
EXCEPTION 
	WHEN FORM_TRIGGER_FAILURE
THEN RAISE;
END;

KEY-COMMIT

Code :

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

1
2
3
4
5
6
7
8
COMMIT;
IF FORM_SUCCESS THEN
	MESSAGE('Modifications enregistrées AVEC succès.');
	message(' ');
ELSE
	MESSAGE('Modifications enregistrées SANS succès.');
	message(' ');
END IF;

J'ai message PRE INS et AVEC succes

Dans la doc sur le commit_form ils passent par la vérif du statut du bloc :

IF :System.Form_Status <> 'QUERY'
THEN
Message('An error prevented your changes from being committed.');
Bell;
RAISE Form_Trigger_Failure;
END IF;

[McM]

Allez je rajoute une couche : Aide de forms toujours : FORM_SUCCESS

Use FORM_SUCCESS to test the outcome of a built-in to determine further processing within any trigger. To get the correct results, you must perform the test immediately after the action executes.
That is, another action should not occur prior to the test.
"Another action" includes both built-ins and PL/SQL assignment statements.
If another action occurs, FORM_SUCCESS may not reflect the status of the built-in you are testing, but of the other, more recently executed action.

FORM_SUCCESS should not be used to test whether a COMMIT_FORM or POST Built-in has succeeded. Because COMMIT_FORM may cause many other triggers to fire, when you evaluate FORM_SUCCESS it may not reflect the status of COMMIT_FORM but of some other, more recently executed built-in.
A more accurate technique is to check that the SYSTEM.FORM_STATUS variable is set to QUERY after the operation is done.

On Microsoft Windows NT, when using HOST to execute a 16-bit application, the FORM_SUCCESS built-in will return TRUE whether the application succeeds or fails.
This is a Microsoft a Win32 issue. 32-bit applications and OS commands will correctly return TRUE if executed sucessfully and FALSE if failed. Invalid commands will return FALSE.

On Windows 95 platforms the FORM_SUCCESS Built-in will always return TRUE for HOST commands which fail. This includes calls to command.com or OS functions, any 16-bit DOS or GUI application, or an invalid command. FORM_SUCCESS will return TRUE for 32-bit applications executed sucessfully and FALSE if failed.

[SheikYerbouti]

C'est vrai que COMMIT_FORM génère trop d'instructions pour pouvoir tester le résultat de FORM_SUCCES ou FORM_FAILURE.

[Magnus]

Honte à moi !
Effectivement McM.

Mais alors quelle alternative pour détecter que KEY-COMMIT a déclenché le trigger PRE-INSERT qui a levé une FORM_TRIGGER_FAILURE ?
Comment détecter un échec sans passer par une variable globale ou autre "astuce" qui risque de s'avérer bancale ?

En tout cas, merci de me répondre les gars