Affectation d'une variable d'un package vers une variable locale sans succès

Version imprimable

Salut!

Voici mon code
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 v_ID := VAIN_PACKAGE.v_ID; v_TableStatus := VAIN_PACKAGE.v_TableStatus; v_FieldStatus := VAIN_PACKAGE.v_FieldStatus; v_OptionStatus := VAIN_PACKAGE.v_OptionStatus; v_OptionValue := VAIN_PACKAGE.v_OptionValue; v_Mat := VAIN_PACKAGE.v_Mat; if VAIN_PACKAGE.v_c = 0 then IF (v_OptionStatus = 'UserField') THEN DELETE FROM TABLE_QUANTUM WHERE Top = 5; END IF; ..................
Et ben ça marche pas! v_OptionStatus = 'UserField' est toujours faux alors que théoriquement c'est vrai quelquefois

Si je change en
Code:

1 2 3 IF (VAIN_PACKAGE.v_OptionStatus = 'UserField') THEN DELETE FROM TABLE_QUANTUM WHERE Top = 5; END IF;
Là c'est OK, je me demande pourquoi v_OptionValue := VAIN_PACKAGE.v_OptionValue fut sans succès?

31/10/2008, 16h05
mnitu
Très probablement parce que au moment de l'attribution
Code:

1 2 v_OptionStatus := VAIN_PACKAGE.v_OptionStatus;
la variable/fonction (?) VAIN_PACKAGE.v_OptionStatus était nulle.
03/11/2008, 14h39
Lucas Panny
Citation:
Envoyé par mnitu

Très probablement parce que au moment de l'attribution

Code:

1 2 v_OptionStatus := VAIN_PACKAGE.v_OptionStatus;

la variable/fonction (?) VAIN_PACKAGE.v_OptionStatus était nulle.
Pourquoi ce serait nulle? alors qu'il y a affectation
Pourquoi lorsqu'on utilise directement le package.variable, ça marche, n'est-ce pas la même chose?
03/11/2008, 14h52
plaineR

Il faudrait afficher la valeur v_OptionStatus et de VAIN_PACKAGE.v_OptionStatus après affectation et avant le test pour comprendre ce qui se passe.
03/11/2008, 15h03
orafrance

j'avais eu ce problème et il me semble que je l'ai réglé en créant une fonction dans le package qui me retourne la valeur de la variable... j'ai jamais creusé sur la cause mais ça doit être un problème d'isolation des mémoires.

Citation:

Envoyé par Lucas Panny

Pourquoi ce serait nulle? alors qu'il y a affectation
Pourquoi lorsqu'on utilise directement le package.variable, ça marche, n'est-ce pas la même chose?

J'ai pensé à une erreur de programmation de type

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
53
54
55
56
 
SQL> create or replace package test
  2  Is
  3    id       number;
  4    function f return number;
  5  end;
  6  /
 
Package crÚÚ.
 
SQL> create or replace package body test is
  2    l_id     number;
  3    Function f return number
  4    Is
  5    begin
  6      l_id := 1;
  7      id := l_id+1;
  8      return l_id;
  9    end;
 10    --
 11  Begin
 12    id := Null;
 13  End;
 14  /
 
Corps de package crÚÚ.
 
SQL>
SQL> set autoprint on
SQL> variable h_id number
SQL> exec :h_id := test.id;
 
ProcÚdure PL/SQL terminÚe avec succÞs.
 
 
      H_ID
----------
 
 
SQL> exec :h_id := test.f;
 
ProcÚdure PL/SQL terminÚe avec succÞs.
 
 
      H_ID
----------
         1
 
SQL> exec :h_id := test.id;
 
ProcÚdure PL/SQL terminÚe avec succÞs.
 
 
      H_ID
----------
         2

04/11/2008, 08h47
bruce-willis

Citation:

Envoyé par orafrance

j'avais eu ce problème et il me semble que je l'ai réglé en créant une fonction dans le package qui me retourne la valeur de la variable... j'ai jamais creusé sur la cause mais ça doit être un problème d'isolation des mémoires.

En effet, après avoir testé vos codes, je suppose aussi qu' c'est un problème d'isolation des mémoires.

Citation:

Envoyé par PlainR

Il faudrait afficher la valeur v_OptionStatus et de VAIN_PACKAGE.v_OptionStatus après affectation et avant le test pour comprendre ce qui se passe.

Et oui c'est NULL
04/11/2008, 11h39
mnitu

Citation:

Envoyé par bruce-willis

En effet, après avoir testé vos codes, je suppose aussi qu' c'est un problème d'isolation des mémoires.

Et oui c'est NULL

Le problème est que derrière cette syntagme il peut bien se cacher n’importe quoi. Donc je me demande si tu peut nous fournir un test. Si non très probablement le problème est dans le code du package.

Voici le code du package
Code:

1 2 3 4 5 6 7 8 9 10 CREATE OR REPLACE PACKAGE BRUCE.VAIN_PACKAGE AS v_compt int ; v_TableStatus varchar2 (4000); v_FieldStatus varchar2 (4000); v_OptionStatus nchar (50); v_OptionValue varchar2 (512); v_Currency int; END ;
En effet, je n'ai de fonctions getter/setter comme en POO!!! Ces attributs s'attribuent des valeurs à partir de trigger after insert
C'est pour cela que je confirme le dire de ORAFRANCE sur l'isolation de la mémoire car si j'ajoute une fonction comme

Code:

FUNCTION f RETURN number;

Ca marche

Citation:
Envoyé par bruce-willis
Voici le code du package
Code:

1 2 3 4 5 6 7 8 9 10 CREATE OR REPLACE PACKAGE BRUCE.VAIN_PACKAGE AS v_compt int ; v_TableStatus varchar2 (4000); v_FieldStatus varchar2 (4000); v_OptionStatus nchar (50); v_OptionValue varchar2 (512); v_Currency int; END ;
En effet, je n'ai de fonctions getter/setter comme en POO!!! Ces attributs s'attribuent des valeurs à partir de trigger after insert
C'est pour cela que je confirme le dire de ORAFRANCE sur l'isolation de la mémoire car si j'ajoute une fonction comme

Code:

FUNCTION f RETURN number;

Ca marche
Désolé mais pour l’instant tu ne fait que confirmer ce que j’ai dit : tes variable définies dans le package ne sont pas initialisés et donc ont la valeur nulle.
Les packages PL/SQL ne sont pas des classes ou des objets dans le sens POO. Et ce que OraFrance dit est : j’ai eu le même type de problème j’ai le résolu en ajoutant une fonction mais je n’ai rien compris pourquoi ce problème est arrivé.
Donc poste un exemple complet et reproductible avec tes triggers etc. ou laisse tomber « l’isolation de la mémoire »!