Discussion :

[hoolako]

un fetch ramene une ligne donc on boucle sur le fetch pour ramener toutes les ligne d'un curseur. si on ajoute un BULK COLLECT ....limit x; est qu'on force le fetch a ramener x lignes avant de faire le traitement???
voila un ptit exemple de code

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
CURSOR cur is SELECT rowid, nom, prenom, code from client where tranche_client = tranche
begin
 OPEN cur;
 loop
  FETCH cur BULK COLLECT INTO lt_rowid, lt_nom, lt_pren, lt_code limit x;
        FOR J IN NVL(lt_rowid.FIRST, 0) .. NVL(lt_rowid.LAST, -1) LOOP
            BEGIN 
			--traitement
			END;
 
			END LOOP;
       EXIT WHEN cur%NOTFOUND;
    END LOOP;
    commit;
CLOSE cur;

une autre question est il possible d' utiliser un order by dans une requete quand cette requette ramene le rowid??
j'espere que ma question est claire

[Pomalaix]

un fetch ramene une ligne donc on boucle sur le fetch pour ramener toutes les ligne d'un curseur. si on ajoute un BULK COLLECT ....limit x; est qu'on force le fetch a ramener x lignes avant de faire le traitement???...
une autre question est il possible d' utiliser un order by dans une requete quand cette requette ramene le rowid??
j'espere que ma question est claire

Bonjour

Quand vous faites un BULK COLLECT basique, le résultat du SELECT est chargé en une seule fois dans la collection désignée. (On n'a alors pas besoin de curseur explicite).
Quand vous faites un FETCH ... BULK COLLECT ... LIMIT 100, vous chargez en une seule fois 100 lignes dans la collection, et vous devez traiter immédiatement ces 100 lignes, car le FETCH suivant remplacera les 100 lignes de la collection par les 100 nouvelles valeurs.

Quant à l'ORDER BY, que voyez-vous de spécial du fait qu'il y ait un ROWID ?

[hoolako]

Merci pour votre réponse , donc ça ne sert a rien de faire loop sur un fetch avec bulk collect dans le cas ou on n'utilise pas de limit?
je vais être un peu plus clair concernant le rowid , voila

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
 
select ROWID, nom, code_cl, num_tel FROM client WHERE STATUS != ds_STATUS;
BEGIN
 v_requete := 'UPDATE client
SET 
code_cl = SEQ_client.nextval,
.
.
.
.
.
WHERE  ROWID        = :9';
 
 
OPEN CUR_client(PKG_CST.c_OK);
    LOOP
    FETCH CUR_client BULK COLLECT INTO lt_ROWID, lt_nom, lt_ccl, lt_num_tel LIMIT frq_COMMIT;
 
        FOR J IN NVL(lt_ROWID.FIRST, 0) .. NVL(lt_ROWID.LAST, -1) LOOP 
          BEGIN 
.
.
.
..
.
 
           execute immediate v_requete USING .............,  lt_ROWID(J);
 
          END;
        END LOOP;
            commit;
    EXIT WHEN CUR_client%NOTFOUND;
    END LOOP;
    CLOSE CUR_client;

en fait je suis en train de mettre à jour la table en me basant sur le rowid et je me demandé si le fait de réorganiser cette table (reorganisation qui pourrait changer le rowid) ne pose pas un problème quand à la coherence de ma requête

[Pomalaix]

en fait je suis en train de mettre à jour la table en me basant sur le rowid et je me demandé si le fait de réorganiser cette table (reorganisation qui pourrait changer le rowid) ne pose pas un problème quand à la coherence de ma requête

Absolument, en toute généralité il est déconseillé d'utiliser le ROWID.
D'une part pour une question théorique, car une base de données relationnelle est censée opérer au niveau "logique", alors que le ROWID est une adresse physique.
D'autre part pour la raison que vous évoquez : l'adresse d'une ligne de données est susceptible de changer en diverses occasions : import, ALTER TABLE MOVE / SHRINK, restauration flashback, etc.

Toute table est censée posséder une clé primaire qui permet d'identifier les lignes de données sans faire appel à leur adresse physique.

[hoolako]

Absolument, en toute généralité il est déconseillé d'utiliser le ROWID.
D'une part pour une question théorique, car une base de données relationnelle est censée opérer au niveau "logique", alors que le ROWID est une adresse physique.
D'autre part pour la raison que vous évoquez : l'adresse d'une ligne de données est susceptible de changer en diverses occasions : import, ALTER TABLE MOVE / SHRINK, restauration flashback, etc.

Toute table est censée posséder une clé primaire qui permet d'identifier les lignes de données sans faire appel à leur adresse physique.

ok je vais changer cela , merci pour ton aide Pomalais

[mnitu]

Avec RowID ou avec clé primaire, peu importe dans ce cas , le traitement est incorrecte sans poser de verrous ! Essayez plutôt de faire un seule update et si cella n’est pas possible n’oubliez pas de commencer par un select <rowid> ou <clé primaire> … from … For update nowait.