Udf in dml statements

Question

can we select udf which contains dml statements?

Answer 1

1007109 wrote:
can we select udf which contains dml statements?
Excellent question! And one that illustrates just how careful you have to be when you ASK questions or provide answers.
As with many things Oracle the correct answer is: it depends.
Yes - you can. And no - you can't. And also, yes - you can!
ANY one of those answers is correct, depending on what assumptions the questioner is making and/or what assumptions that you, the answerer are making.
Sometimes a interviewer will ask this old 'trick' question and then get mad at you if you don't give them the answer that they want even if you give them an answer that is CORRECT and even if you explain WHY your answer is correct.
Some questioners are looking for the answer that Frank gave:
>
A function that performs DML (or that calls another sub-program that performs DML) can NOT be used in a SQL statement, such as SELECT.
>
If you just read the 'restrictions' section in the Advanced App Developer's guide you might come up with the answer that Frank gave.
http://docs.oracle.com/cd/E11882_01/appdev.112/e25518/adfns_packages.htm#i1008107
>
Restrictions
When a new SQL statement is run, checks are made to see if it is logically embedded within the execution of a running SQL statement. This occurs if the statement is run from a trigger or from a subprogram that was in turn invoked from the running SQL statement. In these cases, further checks determine if the new SQL statement is safe in the specific context.
These restrictions are enforced on subprograms:
  A subprogram invoked from a query (SELECT statement) or DML statement cannot end the current transaction, create or rollback to a savepoint, or ALTER the system or session.
  A subprogram invoked from a query or parallelized DML statement cannot run a DML statement or otherwise modify the database.
  A subprogram invoked from a DML statement cannot read or modify the particular table being modified by that DML statement.
>
But then if you read the very next sentence in that doc you will see this:
>
You can avoid these restrictions if the execution of the new SQL statement is not logically embedded in the context of the running statement. PL/SQL autonomous transactions provide one escape (see "Autonomous Transactions" ).
>
And finally if the term DML includes the SELECT statement and the SQL Language doc DOES use it that way
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_1001.htm#i2099257
>
The SELECT statement is a limited form of DML statement in that it can only access data in the database. It cannot manipulate data stored in the database, although it can manipulate the accessed data before returning the results of the query.
>
That doc also lists statements other than the traditional SELECT, INSERT, UPDATE or DELETE
>
Data Manipulation Language (DML) Statements
Data manipulation language (DML) statements access and manipulate data in existing schema objects. These statements do not implicitly commit the current transaction. The data manipulation language statements are:
CALL
DELETE
EXPLAIN PLAN
INSERT
LOCK TABLE
MERGE
SELECT
UPDATE
>
So the CORRECT answer is:
1. No, Frank's answer, if by DML you are only considering INSERT, UPDATE or DELETE statements and you do NOT use the AUTONOMOUS_TRANSACTION pragma.
2. Yes - if DML includes SELECT (LOCK TABLE also works) - you don't need the pragma. A common use of functions is in LOOKUP operations. These functions can be, but should NOT be, called from a sql statement.
3. Yes - if the AUTONOMOUS_TRANSACTION pragma is used. This is NOT recommended.
Try some of the following code examples
>
create or replace function get_dname(p_deptno IN number) return varchar2 is
v_dname dept.dname%type;
begin
  select dname into v_dname from dept where deptno = p_deptno;
  return v_dname;
end;
select empno, ename, deptno, get_dname(deptno) from emp e
where rownum < 4
EMPNO,ENAME,DEPTNO,GET_DNAME(DEPTNO)
7369,SMITH,20,RESEARCH*
7499,ALLEN,30,SALES**
7521,WARD,30,SALES**
create or replace function get_dname1(p_deptno IN number) return varchar2 is
v_dname dept.dname%type;
begin
  update dept set dname = dname || '*' where deptno = p_deptno;
  select dname into v_dname from dept where deptno = p_deptno;
  return v_dname;
end;
select empno, ename, deptno, get_dname1(deptno) from emp e
where rownum < 4
ORA-14551: cannot perform a DML operation inside a query
ORA-06512: at "SCOTT.GET_DNAME1", line 4
create or replace function get_dname2(p_deptno IN number) return varchar2 is
PRAGMA AUTONOMOUS_TRANSACTION;
v_dname dept.dname%type;
begin
  update dept set dname = dname || '*' where deptno = p_deptno;
  commit;
  select dname into v_dname from dept where deptno = p_deptno;
  return v_dname;
end;
select empno, ename, deptno, get_dname2(deptno) from emp e
where rownum < 4
EMPNO,ENAME,DEPTNO,GET_DNAME2(DEPTNO)
7369,SMITH,20,RESEARCH**
7499,ALLEN,30,SALES***
7521,WARD,30,SALES****
create or replace function get_dname3(p_deptno IN number) return varchar2 is
v_dname dept.dname%type;
begin
  lock table emp_copy in share mode;
  select dname into v_dname from dept where deptno = p_deptno;
  return v_dname;
end;
select empno, ename, deptno, get_dname3(deptno) from emp e
where rownum < 4
EMPNO,ENAME,DEPTNO,GET_DNAME2(DEPTNO)
7369,SMITH,20,RESEARCH**
7499,ALLEN,30,SALES***
7521,WARD,30,SALES****
>