I cannot convince why I can't add DML operation inside Oracle Function especially inside cursor loop. I feel Oracle don't support DML operation inside cursor loop.
How can I do If I need to insert into table inside cursor loop? Create new store procedure inside it or something else?
Error Message : cannot perform DML operation inside a query
Here is my function,
CREATE OR REPLACE FUNCTION TEST_FUNC(U_ID IN VARCHAR2)
RETURN VARCHAR2
IS
V_MESSAGE VARCHAR2(30);
CURSOR C_PERSON (V_ID VARCHAR2) IS
SELECT NAME_UPPER
FROM TBL_PERSON
WHERE NAME_UPPER = V_ID;
BEGIN
FOR C_PERSON_CURSOR IN C_PERSON(U_ID)
LOOP
INSERT INTO TMP_PERSON(NAME) VALUES (C_PERSON_CURSOR.NAME_UPPER);
END LOOP;
RETURN V_MESSAGE;
EXCEPTION
WHEN OTHERS THEN
raise_application_error(-20001,'An error was encountered - '||SQLCODE||' -ERROR- '||SQLERRM);
END;
You can use DML inside a PL/SQL function - no problem. However, the function can only be called from PL/SQL, not from SQL - i.e. it can be called like this:
declare
l_message varchar2(30);
begin
l_message := test_func('123');
end;
... but not like this:
select test_func(empno) from emp;
That leads to the error message you posted.
Many people (including me) don't like functions that have "side effects" like this, but that is a matter of best practice and standards, not a technical issue.
You can perform DML operations inside an Oracle PL/SQL function and, although this is generally not a good practice, call it from SQL. The function has to be marked with a pragma AUTONOMOUS_TRANSACTION and the transaction has to be committed or rolled back before exiting the function (see AUTONOMOUS_TRANSACTION Pragma).
You should be aware that this kind of function called from SQL can dramatically degrade your queries performances. I recommend you use it only for audit purposes.
Here is an example script starting from your function:
CREATE TABLE TBL_PERSON (NAME_UPPER VARCHAR2(30));
CREATE TABLE TMP_PERSON (NAME VARCHAR2(30));
INSERT INTO TBL_PERSON (NAME_UPPER) VALUES ('KING');
CREATE OR REPLACE FUNCTION TEST_FUNC(U_ID IN VARCHAR2)
RETURN VARCHAR2
IS
PRAGMA AUTONOMOUS_TRANSACTION; -- Needed to be called from SQL
V_MESSAGE VARCHAR2(2000);
CURSOR C_PERSON (V_ID VARCHAR2) IS
SELECT NAME_UPPER
FROM TBL_PERSON
WHERE NAME_UPPER = V_ID;
BEGIN
FOR C_PERSON_CURSOR IN C_PERSON(U_ID)
LOOP
INSERT INTO TMP_PERSON(NAME) VALUES (C_PERSON_CURSOR.NAME_UPPER);
V_MESSAGE := SQL%ROWCOUNT
|| ' Person record successfully inserted into TMP_PERSON table';
END LOOP;
COMMIT; -- The current autonomous transaction need to be commited
-- before exiting the function.
RETURN V_MESSAGE;
EXCEPTION
WHEN OTHERS THEN
ROLLBACK;
raise_application_error(-20001,'An error was encountered - '||SQLCODE||' -ERROR- '||SQLERRM);
END;
/
PROMPT Call the TEST_FUNC function and insert a new record into TMP_PERSON table
SELECT TEST_FUNC('KING') FROM DUAL;
PROMPT Content of the TMP_PERSON table
COL NAME FOR A30
SELECT * FROM TMP_PERSON;
When running the previous script we get the following output:
Table created.
Table created.
1 row created.
Function created.
Calling the TEST_FUNC function and insert a new record into TMP_PERSON table
TEST_FUNC('KING')
------------------------------------------------------------
1 Person record successfully inserted into TMP_PERSON table
Content of the TMP_PERSON table
NAME
------------------------------
KING
Related
I have an Oracle stored procedure that is called from a .NET application. It runs for over 15 minutes. It is very simple code that inserts into a big table from a smaller table, then clears the smaller table.
My issue is that it runs for like 15 minutes, then it dies. No error messages in the log. Nothing. Just stops running. I have done a SQL trace, no evidence of an issue. Sometimes it works, sometimes it doesn't.
Some consistencies exist - when it does fail, it never gets to the Data Moved Successfully or Exception section. Just appears to stop running.
PROCEDURE C_X_AllocInsertData(
p_AccountTable VARCHAR2,
p_AllocationTable VARCHAR2,
p_YearMonth NUMBER,
p_versionPK NUMBER,
p_returncode OUT NUMBER)
AS PRAGMA AUTONOMOUS_TRANSACTION;
v_OutputTableRowCntSql varchar(32767);
BEGIN
p_returncode:=0;
C_X_VERSIONINSERTLOG(
p_VersionPk
,'Now moving the data from temp table to big table'
,'Now moving the data from temp table to big table'
);
--Now that all operations are complete, delete from account table
v_OutputTableRowCntSql := 'BEGIN delete from '||p_AccountTable||' where YEARMONTH= '||p_YearMonth||'; ';
--Then insert from the TMP table
v_OutputTableRowCntSql := v_OutputTableRowCntSql || 'insert into '||p_AccountTable|| ' SELECT * FROM ' || p_AllocationTable||'; ';
--Then clear the temp table
v_OutputTableRowCntSql := v_OutputTableRowCntSql || 'delete from '||p_AllocationTable||'; END;';
EXECUTE IMMEDIATE v_OutputTableRowCntSql;
C_X_VERSIONINSERTLOG(
p_VersionPk
,'Data moved successfully.'
,'Data moved successfully.'
);
commit;
EXCEPTION
WHEN OTHERS THEN
p_returncode:=-1;
C_X_VERSIONINSERTLOG(
p_VersionPk
,'Insert into big table failed for version #'||p_versionPK||'... Error message was: '||SQLERRM
,'Insert into big table failed. Error message was: '||SQLERRM||' Statement was: '||v_OutputTableRowCntSql
);
END;
It seems that C_X_VERSIONINSERTLOG procedure lacks appropriate error handing...I will add that. Here it is in its original form...could this be the issue?
PROCEDURE C_X_VERSIONINSERTLOG
(
P_VERSIONPK NUMBER,
P_LOGTEXT VARCHAR2,
P_ERROR_MSG VARCHAR2)
AS PRAGMA AUTONOMOUS_TRANSACTION;
v_VersionLogPk C_X_VERSIONLOG.VersionLogPk%TYPE;
BEGIN
SELECT C_X_VERSIONLOG_SEQ.nextval INTO v_VersionLogPk FROM DUAL;
INSERT
INTO C_X_VERSIONLOG
(
VersionLogPk,
VERSIONPK,
VERSIONLOGTEXT,
VERSIONLOGTECHNICALTEXT,
VERSIONLOGDATE
)
VALUES
(
v_VersionLogPk,
P_VERSIONPK,
P_LOGTEXT,
P_ERROR_MSG ,
CURRENT_TIMESTAMP
);
COMMIT;
END C_X_VERSIONINSERTLOG;
I have the following script which contains a function named 'myFunction'. (declaration of types named rowValueTmp and rowValueTable are also attached for your information) Basically, I need to use a table name as an input parameter for myFunction. I found that I need to use dynamic SQL in order to use the table name as a parameter (Please correct me if there are alternative ways to do this). So the following code is what I have tried so far.
create or replace type rowValueTmp as object (
month number,
year number
);
/
create or replace type rowValueTable as table of rowValueTmp;
/
create or replace FUNCTION myFunction (TABLENAME in VARCHAR2)
return rowValueTable as
v_ret rowValueTable;
begin
execute immediate '
select rowValueTmp(month, year)
bulk collect into v_ret
from '||TABLENAME;
return v_ret;
end myFunction;
/
select * from table(myFunction('SCHEMA.TEST'));
But, this code gives me an error, and I assumed that this error is occurred because of using 'bulk collect' in execute immediate block.
ORA-03001: unimplemented feature
If I replace the content of execute immediate as the following, the above script is working..
select rowValueTmp(month, year)
bulk collect into v_ret
from SCHEMA.TEST;
Question
1] Is there any way(rather than Dynamic SQL) that I can use a table name as an input parameter for myFunction?
2] If I am not allowed to use bulk collect in execute immediate block, what do you suggest?
You can return values from execute immediately into a bulk collect:
CREATE OR REPLACE FUNCTION myfunction (tablename IN VARCHAR2)
RETURN rowvaluetable AS
v_ret rowvaluetable;
v_table VARCHAR2 (61) := DBMS_ASSERT.sql_object_name (tablename);
BEGIN
EXECUTE IMMEDIATE '
select rowValueTmp(month, year)
from ' || v_table
BULK COLLECT INTO v_ret;
RETURN v_ret;
END myfunction;
/
In the interest of an abundance of caution, I'd recommend using DBMS_ASSERT to validate the table parameter as well (as shown).
Every time my team does a data refresh to our UAT environment we have issues with the 'auto incremented' columns in oracle They hold onto the old value and therefore cause errors when a new insert happens. The only solution I have found is to use
select test_SEQ.nextval from test_table;
Until the next sequence is bigger then the max seq number in the table. I have over 200 tables to update, is there an easier why to do this?
Thanks
Erin
One better way to do this would be to drop the sequences and create new ones with the desired START WITH value. You could generate the DDL to do this dynamically.
Check the following sqlfiddle http://sqlfiddle.com/#!4/17345/1
It doesn't completely work due to limitations in sqlfiddle, but here's the function that makes it happen:
create or replace function
reset_sequence(p_sequence_name varchar,
p_table_name varchar,
p_column_name varchar)
return integer is
v_temp integer;
v_sql varchar(2000);
begin
v_sql := 'select nvl(max('||p_column_name||'),0)+1 col_name from '||p_table_name;
execute immediate v_sql INTO v_temp;
v_sql := 'drop sequence '||p_sequence_name;
execute immediate v_sql;
v_sql := 'create sequence '||p_sequence_name||' start with '||v_temp;
execute immediate v_sql;
return v_temp;
end;
Basically you call this function and pass a schema name, table name and column name and it will set the function to the correct value. You can put a begin/exception/end block to ignore errors when dropping the sequence, in case it doesn't exist, but all that is just icing. You could also have it detect the column that is the primary key if you wanted, but no real way in Oracle to detect the sequence name.
You could also make a procedure version of this, but I tend to prefer functions for whatever reason.
I'm trying to develop a procedure which will read a BLOB field of a table and write an RTF document which will be used as template to another procedure but when the procedure fires up the select statemente, i got stuck with a ORA-06502 error.
This error, after reading the documentation, is caused by incompatibilities between fields (numeric or value error string)
But i've seen this example everywhere in the internet and i'm running out of ideas of what is causing it.
The source code of my procedure follows:
PROCEDURE p_transfer_db_client(pcPath IN VARCHAR2,
pnSequence IN NUMBER) IS
v_src_blob BLOB;
v_file UTL_FILE.FILE_TYPE;
v_offset INTEGER := 1;
v_amount BINARY_INTEGER := 32766;
v_binary_buffer RAW(32767);
BEGIN
SELECT model
INTO v_src_blob
FROM models
wHERE id = pnSequence;
v_file := UTL_FILE.FOPEN(pcPath, 'model.rtf', 'wb', v_amount);
LOOP
BEGIN
DBMS_LOB.READ(v_src_blob, v_amount, v_offset, v_binary_buffer);
UTL_FILE.PUT_RAW(v_file, v_binary_buffer);
v_offset := v_offset + v_amount;
EXCEPTION
WHEN NO_DATA_FOUND THEN
EXIT;
END;
END LOOP;
UTL_FILE.FFLUSH(v_file);
UTL_FILE.FCLOSE(v_file);
END p_transfer_db_client;
Edit: I hadn't seen that you had tagged this question as forms.
Your code won't work inside forms: UTL_FILE and DBMS_LOB run on the DB server, not the forms client so they should be in a PL/SQL procedure, not a Forms procedure.
I'm pretty sure the BLOB datatype is not managed like this in forms, in fact I'm surprised it even compiles!
Take a look at this example showing how to handle blobs inside forms for instance, and you will see that you need to define and query the blob inside a PLSQL procedure, not directly through forms.
I suggest you create the procedure inside the DB as a PLSQL package and call this package from your forms client.
There is something else going on, I can't see why the SELECT statement wouldn't work.
Do you still get the error if you comment out all variables declarations and all the following statements, i.e:
SQL> create table models (
2 inst_num_instituicao NUMBER(2) not null,
3 id NUMBER(3) not null,
4 model BLOB not null);
Table created.
SQL> insert into models values (1, 1, hextoraw('FFFF'));
1 row created.
SQL> declare
2 b blob;
3 begin
4 select model into b from models where id = 1;
5 end;
6 /
PL/SQL procedure successfully completed.
is there any way to log all failed sql statements in oracle 10g to a table or file?
By failed I mean bad formated sql statement or sql statements that do not have permission for a table or object.
You may want to use Auditing like:
AUDIT SELECT TABLE, INSERT TABLE, DELETE TABLE, EXECUTE PROCEDURE
BY ACCESS
WHENEVER NOT SUCCESSFUL;
By ACCESS is for each statement (which seems like what you want). By SESSION would record one record per session (high volume environment).
Oracle's built in auditing has less overhead then a trigger. A trigger, which other answers contain, allows you to log the exact information you want. Auditing will also only catch hits on existing objects. If someone selects on a non-existent table (misspelled or whatnot) auditing will not catch it. The triggers above will.
A lot more info in the security guide: http://download.oracle.com/docs/cd/B19306_01/network.102/b14266/auditing.htm#i1011984
Rather than hit the system views, as in Demge's answer, there is an ora_sql_txt function that gives the relevant statement.
create or replace TRIGGER log_err after servererror on schema
DECLARE
v_stack VARCHAR2(2000) := substr(dbms_utility.format_error_stack,1,2000);
v_back VARCHAR2(2000);-- := substr(dbms_utility.format_error_backtrace,1,2000);
v_num NUMBER;
v_sql_text ora_name_list_t;
procedure track(p_text in varchar2) is
begin
insert into .... values (p_text);
end;
begin
v_stack := translate(v_stack,'''','"');
track(v_stack);
v_back := translate(v_back,'''','"');
if v_back is not null then track(v_back); end if;
v_num := ora_sql_txt(v_sql_text);
BEGIN
FOR i IN 1..v_num LOOP
track(to_char(i,'0000')||':'||v_sql_text(i));
END LOOP;
EXCEPTION
WHEN VALUE_ERROR THEN NULL;
END;
end;
In my own environment, I actually have 'TRACK' as a separate procedure that uses an autonomous transaction, rather than a block as above.
create or replace procedure track (p_text IN VARCHAR2) IS
PRAGMA AUTONOMOUS_TRANSACTION;
cursor c_user is
select sys_context('USERENV','CLIENT_INFO') client_info,
sys_context('USERENV','CURRENT_SCHEMA') curr_schema,
sys_context('USERENV','CURRENT_USER') curr_user,
sys_context('USERENV','DB_NAME') db_name,
sys_context('USERENV','HOST') host,
sys_context('USERENV','IP_ADDRESS') ip,
sys_context('USERENV','OS_USER') osuser,
sys_context('USERENV','SESSIONID') sessid,
sys_context('USERENV','SESSION_USER') sess_user,
sys_context('USERENV','TERMINAL') terminal
from dual;
user_rec c_user%rowtype;
v_mod VARCHAR2(48);
v_act VARCHAR2(32);
v_cli_info varchar2(64);
begin
open c_user;
fetch c_user into user_rec;
close c_user;
DBMS_APPLICATION_INFO.READ_MODULE (v_mod, v_act);
--DBMS_APPLICATION_INFO.READ_CLIENT_INFO(v_cli_info);
insert into track_detail
(id, track_time, detail, client_info, curr_schema, curr_user, db_name,
host, ip, osuser, sessid, sess_user, terminal, module, action)
values (track_seq.nextval, systimestamp, p_text,
user_rec.client_info, user_rec.curr_schema, user_rec.curr_user,
user_rec.db_name, user_rec.host, user_rec.ip,
user_rec.osuser, user_rec.sessid, user_rec.sess_user,
user_rec.terminal, v_mod, v_act);
commit;
end;
You can do this with a system trigger.
I directly copied this code from http://www.psoug.org/reference/system_trigger.html.
CREATE TABLE servererror_log (
error_datetime TIMESTAMP,
error_user VARCHAR2(30),
db_name VARCHAR2(9),
error_stack VARCHAR2(2000),
captured_sql VARCHAR2(1000));
CREATE OR REPLACE TRIGGER log_server_errors
AFTER SERVERERROR
ON DATABASE
DECLARE
captured_sql VARCHAR2(1000);
BEGIN
SELECT q.sql_text
INTO captured_sql
FROM gv$sql q, gv$sql_cursor c, gv$session s
WHERE s.audsid = audsid
AND s.prev_sql_addr = q.address
AND q.address = c.parent_handle;
INSERT INTO servererror_log
(error_datetime, error_user, db_name,
error_stack, captured_sql)
VALUES
(systimestamp, sys.login_user, sys.database_name,
dbms_utility.format_error_stack, captured_sql);
END log_server_errors;
/