Stored procedure: nested cursor problem

Question

Hey folks,
i am really having a hard time trying to figure out how nested cursors work.
What i want to do:
-> Do one select statement and process the yielded rows with one cursor
-> Do another select statement depending on the first cursor
The code is quite simple, the beginning of the stored procedure is:
create or replace
PROCEDURE extractEntireMD IS
CURSOR curTemplateUnitId IS
SELECT
tu.externalident,
tu.templateunitid
FROM
templateunit tu
WHERE
tu.templateunitid = 100007;
CURSOR curPartTypeId(templateUnitID IN varchar2) IS
SELECT
tpt.parttypeid
FROM
templateparttype tpt
WHERE
tpt.templateunitid = templateUnitID;
From what i have read, this seems to be right.
No i want to use this code like this:
BEGIN
FOR valInCurTemplateUnitId IN curTemplateUnitId LOOP
DBMS_OUTPUT.PUT_LINE('ExtIdent: ' || valInCurTemplateUnitId.externalident);
DBMS_OUTPUT.PUT_LINE('templateunitid: ' || valInCurTemplateUnitId.templateunitid);
FOR valIncurPartTypeId IN curPartTypeId(valInCurTemplateUnitId.templateunitid) LOOP
DBMS_OUTPUT.PUT_LINE('PartTypeId: ' || valIncurPartTypeId.parttypeid);
END LOOP;
END LOOP;
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('No such data ');
END;
The problem:
I seem to be doing something wrong, because Oracle does not heed the argument which i give to the second cursor from the first cursor:
CURSOR curPartTypeId(templateUnitID IN varchar2) IS
which i call via:
FOR valIncurPartTypeId IN curPartTypeId(valInCurTemplateUnitId.templateunitid)
Instead, oracle prints out __all__ templateunitids.
If I modify the second cursor with a constant argument like this:
CURSOR curPartTypeId(templateUnitID IN varchar2) IS
SELECT DISTINCT
tpt.parttypeid
FROM
templateparttype tpt
WHERE
tpt.templateunitid = 100007;
The result is correct. So it seems like oracle simply disregards the parameter i am giving him for the second cursor.
What am i doing wrong?

Answer 1

> i am really having a hard time trying to figure out how nested cursors work.
Good. I trust that this will result in the realisation that it is an idiotic thing to emulate the features of the SQL engine in PL/SQL. Only a fool thinks the he/she can outprogram and outsmart the SQL engine, and do things like nested loop joins better and faster in PL/SQL.
Use SQL for the purpose it was designed. Use PL/SQL for the purpose it was designed.
Joining of data? That is prime function and feature of SQL. Not PL/SQL.