Le problème en est un de résolution de noms.
Lorsque vous avez un paramètre hostname et un hostname colonne dans le tableau auquel vous faites référence, les règles de résolution de portée causent la confusion à la plupart des gens. C'est pourquoi de nombreuses personnes recommandent d'utiliser une convention de dénomination pour les paramètres et les variables locales qui les différencie des noms de table. Dans mon code, par exemple, j'utilise p_ pour préfixer les noms de paramètres et l_ pour préfixer les variables locales.
Dans votre code, lorsque vous avez
SELECT mySystems.SYSTEMID
INTO SysID
FROM mySystems
where mySystems.HOSTNAME = Hostname;
hostname est résolu en tant que colonne de la table, et non en tant que paramètre. Ainsi, la requête renvoie chaque ligne de la table où hostname n'est pas nul, ce qui provoque l'erreur. Vous pouvez explicitement préfixer le nom du paramètre avec le nom de la fonction pour forcer hostname pour résoudre le paramètre
SELECT mySystems.SYSTEMID
INTO SysID
FROM mySystems
where mySystems.HOSTNAME = GET_SYSTEMID.Hostname;
Ça marche. Mais ajouter le préfixe du nom de la fonction devient généralement ennuyeux. Si vous adoptez la convention de préfixer les noms de paramètres et les noms de variables locales, vous obtiendrez quelque chose comme
FUNCTION GET_SYSTEMID(p_hostname varchar2)
RETURN NUMBER
IS
l_sysID number;
BEGIN
SELECT mySystems.SYSTEMID
INTO l_sysID
FROM mySystems
where mySystems.HOSTNAME = p_hostname;
return l_sysID;
END GET_SYSTEMID;
Cela fonctionne également et a tendance (dans mon esprit) à être plus clair que d'ajouter des préfixes de nom de fonction explicites partout.
