INSERT SELECT en dynamique et COMMIT

Version imprimable

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

14/06/2007, 10h52
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 ? :koi:
14/06/2007, 10h55
macben

Citation:

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 ? :koi:

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 ?
14/06/2007, 11h01
orafrance

il y a tuto sur EXECUTE IMMEDIATE sur le site ;)
14/06/2007, 11h10
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 !
14/06/2007, 11h13
macben

Citation:

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...
14/06/2007, 11h23
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
14/06/2007, 11h29
orafrance

non :D

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 :)

On peut utiliser "FORMS_DDL"
Syntax

Citation:

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;

14/06/2007, 12h14
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.
14/06/2007, 12h15
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;

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 !)

14/06/2007, 17h26
plaineR

Citation:

Envoyé par Garuda

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

Exact

Citation:

Envoyé par Garuda

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

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

Citation:

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
14/06/2007, 17h49
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 !
15/06/2007, 09h27
plaineR

Citation:

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.
15/06/2007, 09h44
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 ;)
15/06/2007, 10h19
Garuda

You 're right, old fellows

:oops:
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'