Bad bind variable & best practice for delete

Question

I am working with three tables and very new to SQL. I need to create a procedure that will accept an ID and go through two sub tables and delete child records. Item is the main table. I am passing in the ID into the procedure and I want to use it as below. I keep getting a bad bind variable error message. I have verified that the table is setup as a number and my procedure accepts a number. I also want someone to review this from best practice as I am new to procedures.
PROCEDURE DeleteItem (p_ItemID IN NUMBER, p_RowsAffected OUT number)
IS
p_RowsAffected NUMBER;
-- select the itemdetail for the analysis
CURSOR c_itemdetail
IS
SELECT
itemdetailid
FROM itemDETAIL
WHERE itemid = :p_ItemID;
BEGIN
-- loop through each itemdetail and delete the itemdetailoutlay
FOR r_itemdetail IN c_itemdetail
LOOP
BEGIN
DELETE FROM ITEMDETAILOUTLAY
WHERE itemdetailid = r_itemdetail.itemdetailid;
COMMIT;
END;
END LOOP;
-- delete the itemdetail
BEGIN
DELETE FROM ITEMDETAIL
WHERE itemid = :p_ItemID;
COMMIT;
END;
-- delete the main item
BEGIN
DELETE FROM ITEM
WHERE itemdid = :p_ItemID;
COMMIT;
p_RowsAffected := SQL%ROWCOUNT;
END;
END DeleteItem;

Answer 1

Hi,
Welcome to the forum!
As you may notice, this site normally compresses white-space. Whenever you post code, or any formatted text, on this site, type these 6 characters:
\(small letters only, inside curly brackets) before and after each section of formatted text, to preserve spacing.
I don't think you mean to use bind variables anywhere, so don't use colons before any variable names.  You were doing this correctly with p_RowsAffected; do the same thing with p_ItemID.
Try this:PROCEDURE DeleteItem (p_ItemID IN NUMBER, p_RowsAffected OUT number)
IS
-- p_RowsAffected NUMBER;     -- Don't name local variables the same as arguments
-- select the itemdetail for the analysis
CURSOR c_itemdetail
IS
SELECT
itemdetailid
FROM itemDETAIL
WHERE itemid = p_ItemID;     -- No : before p_ItemID
BEGIN
-- loop through each itemdetail and delete the itemdetailoutlay
FOR r_itemdetail IN c_itemdetail
LOOP
BEGIN
DELETE FROM ITEMDETAILOUTLAY
WHERE itemdetailid = r_itemdetail.itemdetailid;
COMMIT;
END;
END LOOP;
-- delete the itemdetail
BEGIN
DELETE FROM ITEMDETAIL
WHERE itemid = p_ItemID;     -- No : before p_ItemID
COMMIT;
END;
-- delete the main item
BEGIN
DELETE FROM ITEM
WHERE itemdid = p_ItemID;     -- No : before p_ItemID
COMMIT;
p_RowsAffected := SQL%ROWCOUNT;
END;
END DeleteItem;
The most important "best practice" with PL/SQL is to avoid doing it whenever possible. 
If SQL offers a way o do the same thing, it's usally best not to code anything in PL/SQL.
Have you considered foreign key constraints, with "ON DELETE CASCADE"?  That way, you could simply "DELETE FROM item", and all the dependent rows in the other tables would automatically be deleted.   You wouldn't need to remember to call a procedure like this; in fact, you would have no need for a procedure like this.
Given that you do have such a procedure:
You're doing row-by-row processing, which some mad wags like to call "slow-by-slow" processing.
For example, iYou're xplicitly finding each ItemDetailID separately, and deleting each one separately, like this:... CURSOR c_itemdetail
IS
SELECT
itemdetailid
FROM itemDETAIL
WHERE itemid = p_ItemID;
-- loop through each itemdetail and delete the itemdetailoutlay
FOR r_itemdetail IN c_itemdetail
LOOP
BEGIN
DELETE FROM ITEMDETAILOUTLAY
WHERE itemdetailid = r_itemdetail.itemdetailid;
COMMIT;
END;
END LOOP;
It's more efficient for the system (and less coding for you) if you let SQL handle as much as possible, so do this instead...     DELETE FROM ItemDetailOutlay
     WHERE ItemDetailID IN
          ( SELECT itemdetailid
          FROM     itemDETAIL
          WHERE     itemid     = p_ItemID
Do you really want to COMMIT 3 times?  0 or 1 times might be better.
What happens if there is some kind of error, say, after you've delete rows form ItemDetailOutlay and ItemDetail, but before you've delete from Item?  Wouldn't you want the entire transaction to fail, and leave all three tables in a consistent state?  If so, either have the calling procedure COMMIT, or have a single COMMIT at the end of DelteItem.
Edited by: Frank Kulash on May 6, 2010 2:25 PM