Il problema è di risoluzione dei nomi.
Quando hai un parametro hostname e un hostname colonna nella tabella a cui si fa riferimento, le regole di risoluzione dell'ambito creano confusione nella maggior parte delle persone. Ecco perché molte persone consigliano di utilizzare una convenzione di denominazione per i parametri e le variabili locali che li differenzia dai nomi delle tabelle. Nel mio codice, ad esempio, utilizzo p_ per anteporre i nomi dei parametri e l_ per anteporre variabili locali.
Nel tuo codice, quando hai
SELECT mySystems.SYSTEMID
INTO SysID
FROM mySystems
where mySystems.HOSTNAME = Hostname;
hostname viene risolto come la colonna nella tabella, non il parametro. Ciò fa sì che la query restituisca ogni riga nella tabella in cui hostname non è null che causa l'errore. È possibile prefissare esplicitamente il nome del parametro con il nome della funzione per forzare hostname per risolvere il parametro
SELECT mySystems.SYSTEMID
INTO SysID
FROM mySystems
where mySystems.HOSTNAME = GET_SYSTEMID.Hostname;
Che funzioni. Ma l'aggiunta del prefisso del nome della funzione generalmente diventa fastidiosa. Se adotti la convenzione di anteporre i nomi dei parametri e i nomi delle variabili locali, otterresti qualcosa del tipo
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;
Anche questo funziona e tende (nella mia mente) ad essere più chiaro dell'aggiunta di prefissi espliciti dei nomi delle funzioni dappertutto.
