EXECUTE IMMEDIATE pas exécuté immédiatement

Version imprimable

Cela fait quelque temps que je me pose une question par rapport à un fait que j' ai constaté.
Prenons le code suivant:

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
 
declare
i number;
begin
  select  count(*)
  into i
  from user_tables
  where table_name = 'RATE_RC_BKP';
  if i=0
  then
    execute immediate
    'create table rate_rc_bkp as '||
    'select * from rate_rc '||
    'where active_date = ''01/01/2075'' '||
    'and rate_class > 30705 '||
    'and class_of_service_code between 3321 and 3332';
 
    update rate_rc_bkp
    set active_date = '01/01/1975';
 
    delete rate_rc
    where active_date = '01/01/2075'
    and rate_class>30705
    and class_of_service_code between 3321 and 3332;
 
    commit;
 
  end if;
end;
/

Si je l'exécute dans un .sql sous Unix il me renvoie l'erreur suivante:
la table Rate_rc_bkp n'existe pas...

pour que çà marche, il faut que j'utilise ce code ci:

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
 
declare
i number;
begin
  select  count(*)
  into i
  from user_tables
  where table_name = 'RATE_RC_BKP';
  if i=0
  then
    execute immediate
    'create table rate_rc_bkp as '||
    'select * from rate_rc '||
    'where active_date = ''01/01/2075'' '||
    'and rate_class > 30705 '||
    'and class_of_service_code between 3321 and 3332';
  end if;
end;
/
 
update rate_rc_bkp
set active_date = '01/01/1975';
delete rate_rc
where active_date = '01/01/2075'
and rate_class>30705
and class_of_service_code between 3321 and 3332;
commit;
/

Et là plus de soucis de table inexistante.

Pourquoi donc ce EXECUTE IMMEDIATE n'est il pas pris en compte immédiatement???

Pour info je suis en 9.2 et Oracle est instrallé sur Solaris 2.6

11/05/2006, 17h55
SheikYerbouti

L'objet ne sera créé qu'à l'exécution. Il est donc normal que le compilateur plante lorsque vous voulez manipuler un objet qui n'existe pas encore.
11/05/2006, 21h28
dyvim

Merci...

C'était tellement évident que je n'y avais même pas pensé.

Donc pour éviter ce problème il faut ne faire que des "execute immediate" qui ne seront pas compilés ou faire comme je fais et attendre l'éxécution du bloc PL.

A moins qu'il n'y ait un moyen de forcer la compilation?

Je me demandes d'ailleurs bien pourquoi les ordres de création ou d'altération de tables ne peuvent pas être éxécutés directement en PL/SQL. Cela pourrait être utile et le PL existe depuis maintenat bien longtemps mais cette fonctionalié n'a jamais été présente autrement que par le PL/SQL dynamique.
11/05/2006, 22h24
plabrevo
Citation:

Envoyé par dyvim

A moins qu'il n'y ait un moyen de forcer la compilation?

J'ai bien peu que cela soit au-dela des capacites d'un compilateur. Comment pourrait-il interpreter le code source suivant:
Code:

1 2 3 4 5 6 7 DECLARE l_tab VARCHAR2(30); BEGIN l_tab := sysdate; EXECUTE IMMEDIATE 'CREATE TABLE "'||l_tab||'" (n NUMBER)'; END; /
Une remarque en passant. Une syntaxe telle que la suivante est a eviter car elle ne fonctionnera correctement qu'avec un contexte NLS particulier. La bonne methode consiste a utiliser TO_DATE et de specifier explicitement le format DD/MM/YYYY

Code:

set active_date = '01/01/1975';
11/05/2006, 22h43
dyvim

Citation:

Envoyé par plabrevo

Une remarque en passant. Une syntaxe telle que la suivante est a eviter car elle ne fonctionnera correctement qu'avec un contexte NLS particulier. La bonne methode consiste a utiliser TO_DATE et de specifier explicitement le format DD/MM/YYYY

Code:

set active_date = '01/01/1975';

Merci de me le signaler et effectivement je n'utiliserais pas ce genre de code dans une procédure stockée.
Mais là il s'agit d'un script "one-shot" qui vise à corriger des données mal entrées dans la base ('01/01/2075' au lieu de '01/01/1975' :lol:)