Het probleem is er een van naamresolutie.
Als je een parameter hostname
. hebt en een hostname
kolom in de tabel waarnaar u verwijst, veroorzaken de regels voor het oplossen van het bereik de meeste mensen verwarring. Daarom raden veel mensen aan om een naamgevingsconventie voor parameters en lokale variabelen te gebruiken die ze onderscheidt van tabelnamen. In mijn code gebruik ik bijvoorbeeld p_
om parameternamen en l_
. voor te voegen om lokale variabelen vooraf te laten gaan.
In uw code, wanneer u
SELECT mySystems.SYSTEMID
INTO SysID
FROM mySystems
where mySystems.HOSTNAME = Hostname;
hostname
wordt opgelost als de kolom in de tabel, niet als de parameter. Dit zorgt ervoor dat de query elke rij in de tabel retourneert waar hostname
is niet null die de fout veroorzaakt. U kunt de parameternaam expliciet vooraf laten gaan door de functienaam om hostname
te forceren oplossen naar de parameter
SELECT mySystems.SYSTEMID
INTO SysID
FROM mySystems
where mySystems.HOSTNAME = GET_SYSTEMID.Hostname;
Dat werkt. Maar het toevoegen van het voorvoegsel van de functienaam wordt over het algemeen vervelend. Als u de conventie overneemt van het voorvoegsel van parameternamen en lokale variabelenamen, krijgt u zoiets als
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;
Dat werkt ook en is (naar mijn mening) meestal duidelijker dan overal expliciete functienaamprefixen toe te voegen.