La fonction Oracle et la requête renvoient des résultats différents

Question

J'utilise la base de données Oracle 10g.

Fonction est:

create or replace FUNCTION FUNC_FAAL(myCode number,firstDate date 
    , secondDate date) 
    RETURN INTEGER as 
    rtr integer; 
BEGIN 
    select count(*) into rtr 
    from my_table tbl where tbl.myDateColumn between firstDate and 
      secondDate and tbl.kkct is null and tbl.myNumberColumn = myCode ; 
    return (rtr); 
END FUNC_FAAL; 

Cette fonction retourne 117177 comme résultat. Mais si j'exécute la même requête dans la fonction séparément;

select count(*) 
from my_table tbl 
where tbl.myDateColumn between firstDate and secondDate 
and tbl.kkct is null and tbl.myNumberColumn = myCode ; 

-je obtenir un résultat différent 11344 (qui est celui de droite).

Quel peut être le problème?

Merci.

Answer 1

Vous avez obscurci votre code, et je soupçonne que le problème est caché dans le processus. Je soupçonne que votre code est plus comme

create or replace FUNCTION FUNC_FAAL(myNumberColumn number,firstDate date 
    , secondDate date) 
    RETURN INTEGER as 
    rtr integer; 
BEGIN 
    select count(*) into rtr 
    from my_table tbl where tbl.myDateColumn between firstDate and 
      secondDate and tbl.kkct is null and tbl.myNumberColumn = myNumberColumn ; 
    return (rtr); 
END FUNC_FAAL; 

où le paramètre ou variable locale a le même nom que la colonne dans la table. Dans le SQL, la colonne de table est prioritaire et donc la variable n'est pas utilisée et la colonne est comparée à elle-même, ce qui donne un plus grand nombre de correspondances.

Il est préférable de préfixer les variables et les paramètres (par exemple v_ et p_) pour éviter de tels problèmes.

Answer 2

la fonction pourrait être dans un schéma qui a également la table en question. cela pourrait fonctionner par rapport à cette table. Lorsque vous exécutez la requête de manière indépendante, vous pouvez utiliser une table dans un schéma différent. c'est une possibilité. Si tel est le cas, spécifier le nom de la table en tant que nom complet (schema.table) devrait résoudre le problème.

Answer 3

Je cours TKPROF pour voir quel SQL vous traitez réellement dans la base de données, spécifiquement pour voir comment les variables de date sont identifiées.