Execute immediate issue while calling a procedure from plsql block

Question

Hi all,
I have the following simple code ,my execute immediate is not working(I am pasting the error below as well)
CREATE OR REPLACE PROCEDURE CALL_RAHUL_PROCEDURES
AS
strng varchar2(1000);
BEGIN
for i in (select proc_name,flag,id from rahul_procedures order by id)
loop
if (i.flag = 'Y')
then
strng := 'exec '||i.proc_name||'(''rahul'')';
dbms_output.put_line(strng);
execute immediate strng;
end if;
end loop;
END CALL_RAHUL_PROCEDURES;
Error:
Connecting to the database INQDWD.
ORA-00900: invalid SQL statement
ORA-06512: at "ETLADMIN.CALL_RAHUL_PROCEDURES", line 17
ORA-06512: at line 2
exec RAHUL_HELLO_WORLD2('rahul');
Process exited.
Disconnecting from the database INQDWD.
data in rahul_procedures table :
Proc_name flag Id
RAHUL_HELLO_WORLD     N     1
RAHUL_HELLO_WORLD2     Y     2
RAHUL_HELLO_WORLD     N     3
RAHUL_HELLO_WORLD3     N     4
please help.
Regards
Rahul

Answer 1

Mac_Freak_Rahul wrote:
Well I have to call 26 procedures one by one and the names of the procedures would be in a table'rahul_procedures' Which is 100% wrong.
Data is stored in tables, program code is stored in procedures or view defintions.
http://en.wikipedia.org/wiki/Data_%28computing%29
>
Data vs programs
Typically, different files are used to store programs vs data. Executable files contain programs; all other files are data files.
>
So you have just violated the primary distinction between data and program code.
I dont find anything strange in my question,Only because you do not appear to know what you are doing or the difference between data and program code.
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:1943344500346351703
>
ugh, what an ugly "design". I can see your life will be full of performance issues, strange 'bugs', and other unpleasant side effects. I mean, it all looks "so cool", but it'll be a nightmare to maintain and enhance.
but then you have the issue of binds, which will be intractable. You'd have to know the binds at compile time, but you have hidden all of your sql in a magic generic table - so you cannot possibly know your binds at compile time.
I would suggest you discard all of this code (I am DEAD SERIOUS) and start over. This is a bad idea from the get go. Or at least do me a favor and do not use plsql (you make it look like a good database implementation, but it isn't)
The objective here is to store SQL Statements in a Table(a sql repository) and just call the required SQL from the application using the sqlid using the sql_execute procedure. ...
CHANGE YOUR OBJECTIVE.
How about this for a good objective:
the objective here is to store sql statement in a plsql routine (a sql repository, you call a procedure and we run sql) and just call the required sql form the applicatoin using the STORED PROCEDURE
sorry, can I think of hacks to get you going? yes, application contexts come to mind - a fixed number of binds comes to mind. Am I going to work them out? No - it is the wrong way to approach a database application.