Running Cursor script to update Oracle Table.

Question

I have the following script. I have a cursor in which i perform an update operation on a oracle table. But The table "ICS_TRADE_DETAILS " is not getting updated. Am i doing something wrong? I get the correct values populated in the "lastChanged" and "tradeID" fields.
Help Appreciated !!!!
DECLARE
lastChanged VARCHAR2(32);
tradeID VARCHAR2(32);
CURSOR c1 IS
SELECT TRADEID,LASTCHANGED
from CVSELECT;
BEGIN
OPEN c1;
LOOP
FETCH c1 INTO tradeID,lastChanged
DBMS_OUTPUT.PUT_LINE('lastChanged: '||lastChanged);
DBMS_OUTPUT.PUT_LINE('tradeID: '||tradeID);
update ICS_TRADE_DETAILS
SET LASTCHANGED=lastChanged
WHERE CTRADEID=tradeID;
COMMIT;
EXIT WHEN c1%NOTFOUND;
END LOOP;
CLOSE c1;
END;

Answer 1

ji li wrote:
Is this related to someone else pulling data from the table(s) you are updating (and committing frequently)?
If so, wouldn't the undo segments hold enough of the changed data for the dataset to be consistent?
The reason I ask is because I've always been of the impression it was better to commit frequently as opposed to doing autonomous (all or none) processing.When you open a cursor, Oracle needs to fetch data as of that particular SCN. So if someone is potentially updating the table while you are reading data, you want to make sure that Oracle will have the UNDO data in hand to be able to get back to the old state. If you commit in the loop, however, Oracle now believes that your session is no longer interested in older UNDO data so it may well purge that data too quickly, causing ORA-01555 errors. Fetching across a commit is almost certainly a bad idea.
Commit frequency should be driven exclusively by logical units of work. If you have a loop, the logical unit of work is almost always the whole set of rows that you want to process. If processing dies in the middle, you're generally much better off having everything rolled back than in having half the rows processed and not knowing which half were processed and which half were not. If you are processing extremely large numbers of rows (i.e. data warehouse loads), it is sometimes worthwhile to code all the extra logic required to make the process restartable and to commit periodically in order to avoid situations where something dies 2 hours into a run and you have to spend another 2 hours rolling back those changes before you can restart. But that's the exception to the rule and generally only appropriate after spending quite a bit of effort performance tuning which would remove 99% of loops in the first place.
Justin