Calling a function from ananymous block

Question

All,
I have created a function which is to create a table with the given string. Below is the code.
CREATE OR REPLACE
FUNCTION tcr(
name IN VARCHAR2)
RETURN VARCHAR2
IS
vsql VARCHAR2(100);
vmsg VARCHAR2(100);
BEGIN
vsql :='create table '||name||' ( a number(4) )';
EXECUTE immediate vsql;
dbms_output.put_line('craeted');
vmsg:='creation msg';
RETURN vmsg;
EXCEPTION
WHEN OTHERS THEN
RETURN sqlerrm;
END;
When I am calling this from a SELECT stmt giving me the below error
SELECT tcr('test1') FROM dual; ORA-14552: cannot perform a DDL, commit or rollback inside a query or DML
And when I called this from an anonymous block giving me the error again.
DECLARE
vmsg VARCHAR2(200);
BEGIN
vmsg:= tcr('test11');
dbms_output.put_line(vmsg);
END;
ORA-01031: insufficient privilegesCan we use a DDL inside a function and can be called from a SELECT Query. If not what happening inside it when we call from a query, am not able to understand. Expecting a clear explanation.
Thanks
Edited by: 968217 on Apr 17, 2013 11:08 AM

Answer 1

>
Can we use a DDL inside a function and can be called from a SELECT Query. If not what happening inside it when we call from a query, am not able to understand.
>
No - you can NOT use DDL inside a function used in a SELECT query.
See 'Invoking Stored PL/SQL Functions from SQL Statements' in the Advanced Application Developer's Guide
http://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_packages.htm#ADFNS00908
The section 'Controlling Side Effects' has the information about restrictions
>
Restrictions
When a SQL statement is run, checks are made to see if it is logically embedded within the execution of an already running SQL statement. This occurs if the statement is run from a trigger or from a subprogram that was in turn invoked from the already running SQL statement. In these cases, further checks occur to determine if the new SQL statement is safe in the specific context.
The following restrictions are enforced on subprograms:
A subprogram invoked from a query or DML statement might not end the current transaction, create or rollback to a savepoint, or ALTER the system or session.
A subprogram invoked from a query (SELECT) statement or from a parallelized DML statement might not execute a DML statement or otherwise modify the database.
A subprogram invoked from a DML statement might not read or modify the particular table being modified by that DML statement.
>
Since DDL issues a COMMIT it would 'end the current transaction' which, as the first item above says, is not allowed.
Yes - using the AUTONOMOUS_TRANSACTION pragma can side-step that issue but that would be a serious misuse of the functionality.