INSERT SELECT en dynamique et COMMIT [Résolu]

[macben]

Bonjour

j'ai fait un INSERT qui se base sur un SELECT dynamique :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
DECLARE
	LConn_conn_id    EXEC_SQL.CONNTYPE;
	LCu_spec       	EXEC_SQL.CURSTYPE;
	LC_sql_stmt      VARCHAR2(500);
	LI_nIgn        	PLS_INTEGER;
	LC_code_article  VARCHAR2(40);
	LC_description   VARCHAR2(240);
	LC_spec  	VARCHAR2(30);
	i NUMBER;
BEGIN
   LConn_conn_id := EXEC_SQL.DEFAULT_CONNECTION;
   LCu_spec    := EXEC_SQL.OPEN_CURSOR(LConn_conn_id);
  --LC_sql_stmt  := 'INSERT INTO SWM_SPE_DT_1_4 (CODE_ARTICLE, DESCRIPTION, SPECIFICATION) ' || vv_requete_debut || vv_requete_fin;
   LC_sql_stmt  := 'INSERT INTO SWM_SPE_DT_1_4 (CODE_ARTICLE, DESCRIPTION, SPECIFICATION) ' || 'SELECT ''g'', ''h'', ''i'' FROM DUAL';
 
   EXEC_SQL.PARSE(LConn_conn_id, LCu_spec, LC_sql_stmt);
   LI_nIgn := EXEC_SQL.EXECUTE(LConn_conn_id, LCu_spec);
 
   EXEC_SQL.CLOSE_CURSOR(LConn_conn_id, LCu_spec);
   EXEC_SQL.CLOSE_CONNECTION(LConn_conn_id);
  :swm_spe_dt_1_21.description := :swm_spe_dt_1_21.description;
--commit;
   commit_form;
EXCEPTION WHEN EXEC_SQL.PACKAGE_ERROR THEN
   EXEC_SQL.CLOSE_CURSOR(LConn_conn_id, LCu_spec);
   EXEC_SQL.CLOSE_CONNECTION(LConn_conn_id);
END;

le problème est lors du commit ou commit_form, j'ai un message qui me dit qu'aucune modification a eu lieu, du coup j'ai modifié un champ de mon block en lui remettant sa valeur mais j'ai quand même le message.

Comment faire un commit de mon instruction sans forcément committer l'écran ?

Merci

[orafrance]

non mais pour faire un INSERT tu dois créer un nouvel enregistrement en mettant pour chaque champs le résultat de la colonne correspondante. Là tu ne modifie pas le bloc donc c'est normal qu'il te mette ce message. Mais pourquoi tu n'utilises pas EXECUTE IMMEDIATE ?

[macben]

Envoyé par orafrance

non mais pour faire un INSERT tu dois créer un nouvel enregistrement en mettant pour chaque champs le résultat de la colonne correspondante. Là tu ne modifie pas le bloc donc c'est normal qu'il te mette ce message. Mais pourquoi tu n'utilises pas EXECUTE IMMEDIATE ?

euh parce qu'il n'est pas dans l'aide de forms...

je fais execute immediate mon ordre insert et c'est bon ?

le commit se fait comment ?

[orafrance]

il y a tuto sur EXECUTE IMMEDIATE sur le site

[Garuda]

Si tu fais COMMIT_FORM et que tu as modifié la BDD par des ordres SQL directs (ex INSERT, UPDATE etc) sans passer par des BLOCKS/ITEM , Forms croit que tu n'as rien modifié.

MAis de mémoire, le commit se fait quand même=> ne pas tenir compte du message !

[macben]

Envoyé par Garuda

Si tu fais COMMIT_FORM et que tu as modifié la BDD par des ordres SQL directs (ex INSERT, UPDATE etc) sans passer par des BLOCKS/ITEM , Forms croit que tu n'as rien modifié.

MAis de mémoire, le commit se fait quand même=> ne pas tenir compte du message !

En effet le commit se fait quand même, mais pour éviter le message j'ai fait des modifs mais je l'ai quand même, quand à l'ignoré, j'en parle à mes utilisateurs ;-)

en attendant, je vais lire le tuto...

[macben]

ORAFRANCE es-tu sûr que le EXECUTE IMMEDIATE est possible sous Forms ?

Je mets le lien du tuto pour les prochains lecteurs : Lien TUTO execute immediate

[orafrance]

non

mais si c'est pas possible tu crées une procédure stockée plutôt qu'une procédure dans la forms... PL/SQL, lui, fonctionne parfaitement

[Garuda]

On peut utiliser "FORMS_DDL"
Syntax

FUNCTION FORMS_DDL
(statement VARCHAR2);
Built-in Type unrestricted function
Enter Query Mode yes

Parameters

statement Any string expression up to 32K:

n a literal

n an expression or a variable representing the text of a block of dynamically created PL/SQL code

n a DML statement or

n a DDL statement

Usage Notes

Commit (or roll back) all pending changes before you issue the FORMS_DDL command. All DDL operations issue an implicit COMMIT and will end the current transaction without allowing Form Builder to process any pending changes, as well as losing any locks Form Builder may have acquired.

Quand au message, on peut le "trapper" dans le trigger "ON_ERROR" ET "ON_MESSAGE"

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
DECLARE 
  errnum NUMBER       := ERROR_CODE; 
  errtxt VARCHAR2(128) := ERROR_TEXT; 
  errtyp VARCHAR2(16)  := ERROR_TYPE; 
BEGIN 
	-- on trappe le message 'NO CHANGES TO APPLY'
  IF errnum = 40405 THEN 
    NULL;
  ELSIF errnum = 40600 THEN
  	pkgpluton.Msgalert('MSG00016','','E',FALSE,'','Enregistrement déja saisi !');
  	RAISE Form_Trigger_Failure; 
  ELSE 
    Message(errtyp||'-'||TO_CHAR(errnum)||': '||errtxt); 
    RAISE Form_Trigger_Failure; 
  END IF; 
END;

[Magnus]

Sous forms, quand je n'utilise pas une procédure stockée avec EXECUTE IMMEDIATE, j'utilise le packages EXEC_SQL qui permet de construire des requête dynamiques.
Je ne sais pas si ce dernier supporte les requêtes DDL.

[plaineR]

Non :
- il n'est pas possible d'utiliser execute immediate dans forms
- forms_ddl sert à executer des instructions... DDL, pour faire du SQL dynamique avec forms c'est exec_sql (voire dbms_sql)


Pour que le message ne s'affiche pas il suffit de faire :

Code :

1
2
3
:system.message_level := 5;
commit_form;
:system.message_level := 0;

[Garuda]

1) Forms_DDl marche aussi pour du DML (voir HELP FORMS)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
Example 3:
 
/*  
** Built-in:  FORMS_DDL
** Example:   The statement parameter can be a block 
**            of dynamically created PL/SQL code. 
*/ 
DECLARE 
  procname VARCHAR2(30); 
BEGIN 
  IF :global.flag = 'TRUE' THEN 
    procname := 'Assign_New_Employer'; 
  ELSE 
    procname := 'Update_New_Employer'; 
  END IF; 
  Forms_DDL('Begin '|| procname ||'; End;'); 
  IF NOT Form_Success THEN 
    Message ('Employee Maintenance Failed'); 
  ELSE 
    Message ('Employee Maintenance Successful'); 
  END IF; 
END;

Largement suffisant pour faire de simples 'INSERT' !

2) Modifier le level n'empeche pas l'affichage du message (il est moins visible, c'est tout !)

[plaineR]

Envoyé par Garuda

1) Forms_DDL marche aussi pour du DML (voir HELP FORMS)

Exact

Envoyé par Garuda

2) Modifier le level n'empeche pas l'affichage du message (il est moins visible, c'est tout !)

Il n'est même plus visible du tout :

Forms Runtime messages are ranked by severity. Use the SYSTEM.MESSAGE_LEVEL system variable to can control the minimum severity level that displays to end users. There are six levels of message severity that you can affect, listed here in increasing order of severity. Level Message Description
0 All types of messages from the other levels of severity.
5 Reaffirms an obvious condition.
10 Indicates that the end user has made a procedural mistake.
15 Declares that the end user is attempting to perform a function for which the form is not designed.
20 Indicates a condition where the end user cannot continue an intended action due to a problem with a trigger or another outstanding condition.
25 Indicates a condition that could result in the form performing incorrectly.
>25 Indicates a message severity level that you cannot suppress via the SYSTEM.MESSAGE_LEVEL system variable

[Garuda]

Le problème, c'est que si tu as une autre erreur (qui n'est pas celle dont on parle) plus grave (on peut tout imaginer), tu n'auras pas de message !
Avce la solution du ON_ERROR, si !

[plaineR]

Envoyé par Garuda

Le problème, c'est que si tu as une autre erreur (qui n'est pas celle dont on parle) plus grave (on peut tout imaginer), tu n'auras pas de message !

Bien sûr que si, puisque tu changes le niveau d'erreur que pour le commit et que pour les messages de niveau informatif (pour le commit, je ne connais pas d'autres message informatif que celui-ci...) Cela fait des années que j'utilise cette technique est elle n'a jamais posé de problème. Fais également une recherche sur ce forum et tu verras qu'à ce genre de problèmatique d'autres que moi ont proposé cette solution.

[orafrance]

je confirme en effet que la solution de Plainer fonctionne parfaitement, je l'ai moi-même utiliser dans mon ancienne vie de développeur Forms

[Garuda]

J'ai retesté votre solution, ca marche.

Cependant, j'ai des routines que j'utilise depuis des années (10 ? 12) et qui emploient cette technique (surcharge de on_error), documentée par ORACLE.
AVANTAGE :
-on peut voir les autres messages de meme niveau
- On peut traduire les messages (applications multi-langues)
INCONVENIENT : utilisation d'un trigger 'ON_XXXXXX'