Passer un tableau en paramètre d'un IN

Version imprimable

Bonjour,

est-il possible de passer en paramètre d'un IN une variable de type TABLE OF ?

en gros faire truc comme ce-ci mais différement car le code ne fonctionne pas :)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 DECLARE TYPE myTableType IS TABLE OF NUMBER INDEX BY LONG; myTable myTableType; begin myTable (1) := 45; myTable (2) := 60; FOR C1 IN (select * from MATABLE where TABLE_ID IN myTable ) LOOP dbms_output.put_line('Valeur trouvée :' || C1.TABLE_ID); END LOOP; end;
Merci d'avance

30/03/2009, 14h04
orafrance

Un des moyens est d'utiliser une table temporaire
30/03/2009, 14h42
mnitu

Regarde si l'exemple posté ici réponde à ta question.
30/03/2009, 15h06
Severn

Déjà si tu veux manipuler ton type avec du sql, il faut le créer en type stocké.

Le IN ne fonctionnera pas directement sur ta variable, il faudra utiliser une syntaxe sql: select * from table(myTable)

Attention à la scalabilité de ton code en utilisant ce genre de syntaxe, il est parfois meilleur d'utiliser une solution à base de table temporaire comme le propose orafrance si les volumes à traiter deviennent importants.

(par ailleurs, j'ai pas bien compris l'intérêt d'un long pour indexer ton tableau :koi:)
30/03/2009, 16h11
jsd03

Merci à tous, le problème est résolu en passant par une table temporaire :yaisse2:
30/03/2009, 17h08
mnitu

Dommage, c'est plutôt une mauvaise solution.
30/03/2009, 17h38
orafrance

pourquoi ?
30/03/2009, 17h50
jsd03

Citation:

Envoyé par mnitu

Dommage, c'est plutôt une mauvaise solution.

Oui pourquoi ?

Parce que si au départ le choix d'un tableau associatif n'est pas totalement erroné alors il n'y a pas besoin de passer par une table temporaire.
La solution avec la table temporaire signifie déjà la création (et maintenance) d'un nouveau objet dans la base. En plus, des temps de réponse plus longs due aux opérations de copie des donnés se trouvant déjà dans la mémoire dans le tableau en question vers la table temporaire, plus la suppression des données de ce table, etc. doivent être observés.

Je pense que la solution suivante devrait faire l'affaire

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 
CREATE OR REPLACE type tab_nr AS TABLE of number
/
CREATE OR REPLACE PACKAGE cols_pkg AS
  Type gt_number Is Table of Number Index By Binary_Integer;  
 
  procedure init;
  function f_pipe return tab_nr Pipelined;   
  END cols_pkg;
/
 
CREATE OR REPLACE PACKAGE BODY cols_pkg AS
  g_eno gt_number;
  --
  Procedure Init Is
  Begin
    g_eno(1) := 7369;
    g_eno(2) := 7499;      
    g_eno(3) := 7521;
  End;
  --
  Function f_pipe return tab_nr Pipelined Is
    i number;
  Begin
     i := g_eno.first;
     While i Is Not Null Loop
       pipe row(g_eno(i));
       i := g_eno.next(i);
     End Loop;
 
  End; 
  --
Begin
  Init;    
END cols_pkg;
/
 
mni@DIANA> begin
  2    --
  3    FOR crs IN (SELECT ename
  4                  FROM emp e
  5                 WHERE e.empno in (Select t.column_value
  6                                     from table(cols_pkg.f_pipe) t))
  7    Loop
  8      --
  9      dbms_output.put_line(crs.ename);
 10    End Loop;
 11  end;
 12  /
SMITH
ALLEN
WARD

01/04/2009, 08h35
jsd03

Je pensais pas qu'on pouvait faire des choses comme ça :mouarf:. J'essaierai pour voir les performances de la première méthode et de la tienne.

Merci encore
01/04/2009, 10h00
orafrance

Attention tout de même pour les gros tables, une temporary table peut être bien plus intéressante quand même... faut tester quoi ;)
01/04/2009, 10h46
mnitu

Citation:

Envoyé par orafrance

Attention tout de même pour les gros tables, une temporary table peut être bien plus intéressante quand même... faut tester quoi ;)

Si c'était de gros tables le choix d'un tableau associatif n'est peut être pas la bonne.
D'une manière générale essayez de ne pas utiliser les tables temporaires. Dans 99% des cas c'est un signe d'une incompréhension du traitement relationnel surtout pour Oracle. Il semblerait que ce n'est pas le cas avec Sql Server.
01/04/2009, 11h14
orafrance

C'est pas toujours évident d'ajouter une table au MPD notamment quand ce sont des metadata. Ceci étant, tu as raison, j'en ai pas vu souvent et je m'en suis très rarement servi ;)
01/04/2009, 14h02
jsd03

Merci pour ces compléments d'informations.