Discussion :

[macben]

Bonjour

sous Forms 6i je possède une liste d'enregistrements .

Au chargement 5 enregistrements sont ramenés et affichés. Ensuite quand l'utilisateur descend les enregistrement sont chargés/affichés au fur et à mesure

l'utilisateur : a la possibilité d'insérer un nouvel enregistrement. Le problème se pose lors de la validation de l'enregistrement car la liste est automatiquement commitée puis rechargée mais le curseur ne se repositionne pas sur l'enregistrement qui vient d'être inséré

existe-il un petit truc simple pour celui-ci reste sur le nouvel enregistrement :

[orafrance]

avant le commit tu sauves le current_record_indicator (à vérifier ) dans une variable et après tu fait un GO_RECORD

[Nounoursonne]

en faisant tout simplement un Last_Record, cela devrait marcher

[orafrance]

pas si il a inséré le record en plein milieu

[Nounoursonne]

oooops désolé

[macben]

j'essaye tout ça

quand on inssère en plein milieu après le commit l'enregistrement se retrouve systématiquement à la fin car je fais aucun tri

mais je vais quand même faire la solution de orafrance car sinon je jour où je mettrais un tri

[plaineR]

avant le commit tu sauves le current_record_indicator (à vérifier ) dans une variable et après tu fait un GO_RECORD

Cela fonctionne uniquement si :
- tu n'as pas de clause order by (sinon ton enregistrement inséré n'est plus obligatoirement à l'endroit où tu l'as inséré)
- si tu ramènes les mêmes enregistrements (il ne faut pas que l'utilisateur ait fait un enter-query avant d'insérer son enregistrement)

Mais bon, il n'y a pas d'autres solutions (à ma connaissance)

[SheikYerbouti]

... la liste est automatiquement commitée puis rechargée ...

Pourquoi est-elle rechargée ?

[macben]

euh

parce que c'est comme ça :

Non en fait je ne sais pas si elle est rechargée, mais le fait que la ligne se déplace en dernier enregistrement lorsqu'elle est insérée entre 2 autres, et le fait que le curseur change d'enregistrement "J'ai" supposé que ... il y avait rechargement

[SheikYerbouti]

Il faut conserver la valeur de la PK dans une variavle globale dans le trigger de niveau bloc : POST-INSERT

Et ensuite, après l'instruction execute_query (puisqu'elle doit apparament exister) boucler sur les enregistrements jusqu'àu correspondant

Trigger POST-INSERT :

Code :

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

:global.new_cle := :block.item_pk ;

Code qui contient le execute query :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
execute_query ;
If :global.new_cle IS NOT NULL Then
First_record ;
Loop
  If :block.item = :global.new_cle Then
     -- trouvé ! --
     Exit ;
  End if ;
  If :system.last_record = 'TRUE' Then
     First_record ;
     Exit ;
  End if ;
  Next_record ;
End loop ;
End if ;

[ouistitis]

Bonjour et merci pour l'astuce.

Le post date un peu, mais la solution du "first_record", "loop", "next_record" fonctionne toujours à merveille.

[macben]

[plaineR]

Et ensuite, après l'instruction execute_query (puisqu'elle doit apparament exister) boucler sur les enregistrements jusqu'àu correspondant

Ca marche bien si tu n'as pas trop d'enregistrements, sinon les perf en prenne un coup...

C'est quand même dommage qu'il n'y ait pas une commande qui permette de raffraichir les valeurs des champs en fonction de ce qu'il y a dans la base, sans avoir à faire d'execute_query

[SheikYerbouti]

Très honnêtement, je ne vois pas la plus-value de refaire execute_query après un insert !!!

[plaineR]

Quand il y a des triggers ! Ou alors il faut reporter tout le code des triggers de la base de données dans les triggers de forms, ce qui est un peu lourd à maintenir...

Mais le problème du raffraichissement des champs ne se pose pas seulement lors des insert : par exemple quand on a un bouton qui appelle une procédure stockée qui fait des mises à jour, il faut refaire un execute_query, ce qui n'est pas l'idéal...

[orafrance]

D'où l'intérêt de travailler sur des program unit et pas directement dans les triggers

[plaineR]

D'où l'intérêt de travailler sur des program unit et pas directement dans les triggers

: Je ne vois pas le rapport ! Il y a des tables pour lesquelles les insertions peuvent être faites via des forms et via des traitements. Pour éviter d'avoir tout à gérer et dans les forms et dans les traitements on gère cela on niveau des triggers de la base de données. Le problème dans forms est que :
1. On ne voit pas en temps réel ce qui est dans la base de données puisque certains champs ont été renseignés par les triggers
2. Les enregistrements sont vérouillés puisque mis à jour par le trigger

=> d'où l'obligation de faire un execute_query.

[SheikYerbouti]

En fait, il suffit de forcer l'exécution du trigger POST-QUERY pour synchroniser les valeurs.

Créer un trigger POST-INSERT et POST-UPDATE sur le bloc et ajouter l'instruction suivante :

Code :

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

execute_trigger('POST-QUERY');

L'inconvénient mineur réside dans le fait qu'un nouvel enregistrement inséré n'est pas réordonné vis à vis de la clause ORDER BY.
l'avantage majeur réside dans le fait qu'il n'est pas nécessaire de refaire le query de tout le bloc.

[SheikYerbouti]

Maintenant, si un post-query ne suffit pas à retrouver les informations (cas des colonnes mises à jour par une procédure stockée) voici une autre solution un tantinet plus lourde :

-- Script de la table de test --

Code :

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

1
2
3
4
5
6
CREATE TABLE TEST2 ( 
  COL1  VARCHAR2 (100)  NOT NULL, 
  COL2  VARCHAR2 (50), 
  SAL   NUMBER (6,2), 
  COMM  NUMBER (6,2), 
  PRIMARY KEY ( COL1 ) ) ;

-- Fonction stockée en base (SQL dynamique) --

Code :

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

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
CREATE OR REPLACE FUNCTION FORMS_NUM_REC
  (
	PC$Table  IN VARCHAR2, -- Nom de la table
	PC$Where  IN VARCHAR2, -- Clause DEFAULT_WHERE du bloc
	PC$Where2 IN VARCHAR2, -- Clause Where de l'item
	PC$Order  IN VARCHAR2  -- Clause ORDER_BY du bloc
  ) RETURN PLS_INTEGER
IS
  LC$Req  VARCHAR2(2000) ;
  LN$Rec  PLS_INTEGER ;
BEGIN
  ---------------------------------------------------------------------------------------
  -- Cette fonction permet de traiter une requête du type :                            --
  -- SELECT COUNT(*) FROM TEST2 WHERE COL1 < 'nom5' AND COL1 <= 'nom201' ORDER BY COL1 --
  --                                                                                   --
  -- et de retourner le numéro d'ordre du nouvel enregistrement                        --
  ---------------------------------------------------------------------------------------
 
  LC$Req := 'SELECT COUNT(*) FROM ' || PC$Table ;
 
  If TRIM(PC$Where) IS NOT NULL Then
    LC$Req := LC$Req || ' WHERE ' || PC$Where ;
  End if ;
 
  If TRIM(PC$Where2) IS NOT NULL Then
    If TRIM(PC$Where) IS NOT NULL Then
	   LC$Req := LC$Req || ' AND ' || PC$Where2 ;
	Else
	   LC$Req := LC$Req || ' WHERE ' || PC$Where2 ;	
	End if ;
  End if ;  
 
  If TRIM(PC$Order) IS NOT NULL Then
    LC$Req := LC$Req || ' ORDER BY ' || PC$Order ;
  End if ;
 
  EXECUTE IMMEDIATE LC$Req INTO LN$Rec ;
 
  RETURN( LN$Rec ) ;
 
END FORMS_NUM_REC ;
/

-- Fonction a placer dans une librairie PL/SQL Forms (.pll) --

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
FUNCTION Get_Num_Rec( PC$Clause IN VARCHAR2 ) RETURN PLS_INTEGER IS
	LC$Bloc  Varchar(60) := Name_In('system.trigger_block') ;
	LC$Table Varchar2(30) ;
	LC$Source Varchar2(30) ;	
	LC$Where Varchar2(256) ;
	LC$Order Varchar2(256) ;
	LN$Rec Pls_integer ;	
Begin
	LC$Table := Get_Block_Property( LC$Bloc, DML_DATA_TARGET_NAME ) ;
	LC$Source := Get_Block_Property( LC$Bloc, QUERY_DATA_SOURCE_NAME ) ;	
	LC$Where := Get_Block_Property( LC$Bloc, DEFAULT_WHERE ) ;
	LC$Order := Get_Block_Property( LC$Bloc, ORDER_BY ) ;
 
  -- Appel de la fonction stockée --
  LN$Rec := FORMS_NUM_REC(
    LC$Table,
    LC$Where,
    PC$Clause,
    LC$Order ) ;
 
  RETURN( LN$Rec ) ;
 
End ;

-- Dans la forme --
Trigger WHEN-NEW-FORM-INSTANCE :

Code :

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

1
2
-- Création de la variable globale --
:GLOBAL.Num_Rec := '' ;

Trigger POST-INSERT :

Code :

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

1
2
3
4
Begin
  -- Appel de la fonction en librairie PL/SQL --
  :GLOBAL.Rec_Num := GET_NUM_REC( 'COL1 <= ''' || :TEST2.COL1 || '''' ) ;
End ;

Trigger KEY-COMMIT :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Begin
 
  commit_form ;
 
  If :GLOBAL.Rec_Num IS NOT NULL Then
	execute_query ;
	-- Saut direct à l'enregitrement concerné --	  
	Go_Record( :GLOBAL.Rec_Num ) ;
  End if ;	
 
End ;

ATTENTION : La propriété Query All Records du bloc doit être à TRUE
Cette solution ne fonctionne pas si tous les enregistrements ne sont pas lus


Dernière solution :
Dans le trigger POST-INSERT :

- récupérer le ROWID créé : :GLOBAL.rowid := :BLOC.ROWID ;
- Lire l'enregistrement en base
- Appliquer les nouvelles valeurs aux items de l'enregistrement
- Replacer le statut de l'enregistrement à QUERY :
Set_Record_Property( Get_Block_Property( 'nom_bloc', CURRENT_RECORD ), 'nom_bloc', STATUS, QUERY_STATUS ) ;

[plaineR]

Merci pour tous ces exemples !

J'ai essayé les différentes solutions :
1. La première ne fonctionne pas ou alors je n'ai pas compris ce qu'il fallait faire, Sheik, peux-tu préciser STP ?

2. Le deuxième fonctionne sans problème, si ce n'est qu'il faut tenir compte des champs entrés en ENTER-QUERY

3. La troisième me renvoie comme je le pensais le message d'erreur FRM-40654 "Enregistrement mis à jour par un autre utilisateur"