Problem in working with multiple cursors in pl/sql block

Question

I want to develop a procedure to update the values of a colunm for each table.
Output of cursor (cur_ttbl)will be like :
Table Name column_name
Tab1 Col1
Tab2 col2
tab3 col3
Now see below code : In below code I want to append the logic to create a update script to update the table/column returned by first cursor.. I know we have to create a second cursor to go through each record and update that... please suggest the code to do same.
CREATE OR REPLACE PROCEDURE SOL_TEST(p_message_out OUT VARCHAR2,p_err_ind_out OUT NUMBER)
IS
CURSOR cur_ttbl IS
SELECT table_name,column_name
FROM port_table;
lv_SQL_Txt VARCHAR2(4096);
v_COLNM VARCHAR2(200);
BEGIN
FOR rec_ttbl IN cur_ttbl LOOP
v_COLNM := rec_ttbl.column_name;
-- Upper case A replacement
IF INSTR(v_COLNM,chr(63),1) <> 0
THEN v_COLNM := TRANSLATE(v_COLNM,chr(63),chr(42));
END IF;
-- Update the Clintrial record
lv_SQL_Txt := 'UPDATE ' || cur_ttbl.table_name || ' SET ' || cur_ttbl.column_name || ' = TRIM('||v_COLNM||'), ' ' WHERE '|| 'STATUS= 0 AND STAT= ' || '''' || 'N' || '''';
EXECUTE IMMEDIATE lv_SQL_Txt;
lv_SQL_Txt := 'COMMIT';
EXECUTE IMMEDIATE lv_SQL_Txt;
END LOOP;
p_err_ind_out := 0;
p_message_out := '''';
EXCEPTION
WHEN NO_DATA_FOUND THEN NULL;
WHEN OTHERS THEN
p_err_ind_out := 1;
p_message_out := SUBSTR(SQLERRM,1,132);
END;
/

Answer 1

Devgan wrote:
I want to develop a procedure to update the values of a colunm for each table.To be brutally honest - I see everything wrong with this sample procedure and nothing correct.
It does not use exceptions. Exceptions are the de facto standard in modern language - not return codes and messages.
It does not use bind variables for the dynamic SQL created. That will result in a lot of hard parsing (that will reduce that loop's performance by 500% or more). It will also fragment the Shared Pool. A fragmented Shared Pool will cause memory allocation errors.
The data model, judging from the select and update, uses column and table names as attributes. That is a fundamental violation of data modeling and makes absolutely no sense at all in relational design.
Still, I suspect that you will ignore these issues (as it seemed was done and lead to this code) and persist in doing it this "+special+" way. In which case, try not to run too hard into the brick wall. And no, one cannot hack holes in that wall. It can only be removed by adhering to fundamentals - from relational design and physical database implementation, to design and coding in PL/SQL and SQL.