Need to skip unique constraint [message #297051] |
Wed, 30 January 2008 00:33  |
catchme_lenin
Messages: 35 Registered: January 2008 Location: Dubai
|
Member |
|
|
Hi Guruji,
I need to raise an exception for skipping unique constraint error.
The scenario is as follows:
The data flows from different remote tables to my table. A procedure is doing a process and calculations. Finally it is inserting the data in to a table with the calculation.
A job is firing the procedure daily at once.
Recently what happens, an unique constraint error is raised and the procedure stops.
I am invstigting to find out the root cause of unique constraint error. But, it is taking a long time.
Well. now I need to raise an exception to handle the unique constraint error. That means, even if the unique constraint raises,
1. The process of the procedure should not be stopped. It should carry with the next available data.
2. The data (or row), in which the unique constraint was raised, should be trapped in a new 'Trap_unq_err' table. It will help me to findout which are the rows is the root cause for the error.
Warm Regds,
Lenin.
|
|
|
Re: Need to skip unique constraint [message #297058 is a reply to message #297051] |
Wed, 30 January 2008 00:45   |
 |
Littlefoot
Messages: 21823 Registered: June 2005 Location: Croatia, Europe
|
Senior Member Account Moderator |
|
|
If this "computing" is done in a loop, put additional BEGIN-EXCEPTION-END block within the loop. Exception handler should handle exceptions (you may even use WHEN OTHERS as you sad that you'd like to log errors). Something like this:DECLARE
l_computed_value NUMBER;
l_errmsg VARCHAR2(500);
BEGIN
FOR cur_r IN (SELECT id, name FROM some_table)
LOOP
BEGIN
l_computed_value := do_some_computing_here;
INSERT INTO your_table (id, name, computed_value)
VALUES
(cur_r.id, cur_r.name, l_computed_value);
EXCEPTION
WHEN OTHERS THEN
l_errmsg := SQLERRM;
INSERT INTO err_log_table (id, err)
VALUES
(cur_r.id, l_errmsg);
END;
END LOOP;
END;
|
|
|
|
|
|
|
Re: Need to skip unique constraint [message #297095 is a reply to message #297051] |
Wed, 30 January 2008 02:37   |
 |
Littlefoot
Messages: 21823 Registered: June 2005 Location: Croatia, Europe
|
Senior Member Account Moderator |
|
|
Gee ... yes, you are right and I am wrong (generally speaking).
However, in my opinion, ascatchme_lenin wrote on Wed, 30 January 2008 07:33 | Recently what happens, an unique constraint error is raised and the procedure stops.
I am investigating to find out the root cause of unique constraint error. But, it is taking a long time.
| I've suggested a quick and dirty solution to the problem. It is not perfect, but - it really might help this procedure to do the job until the root cause is found.
Both
Quote: | 1. The process of the procedure should not be stopped. It should carry with the next available data.
2. The data (or row), in which the unique constraint was raised, should be trapped in a new 'Trap_unq_err' table.
| requirements are satisfied. "What if" might happen, or might not. If it happens, I'm sure Lenin will return (just like Batman did) and ask for help. Until then, I'd give (my) WHEN OTHERS a try.
|
|
|
|
Re: Need to skip unique constraint [message #297112 is a reply to message #297051] |
Wed, 30 January 2008 03:21   |
catchme_lenin
Messages: 35 Registered: January 2008 Location: Dubai
|
Member |
|
|
Hi all masters,
Thnk you all.
I tried with Littlefoot code in a sample scenario. Using FOR Loop and Cursor. It meets my requirement
1. The procedure is not get stopped when an unique constraint raised. It is carrying out with next available record.
2. It traps the records, which are raising Unique Constraint error.
I have used WHEN DUP_VAL_ON_INDEX THEN exception to trap the error rows and used WHEN OTHERS THEN for other errors.
Thank you all once again.
-Lenin.
|
|
|
|
|
|
Re: Need to skip unique constraint [message #297186 is a reply to message #297132] |
Wed, 30 January 2008 09:21   |
 |
Littlefoot
Messages: 21823 Registered: June 2005 Location: Croatia, Europe
|
Senior Member Account Moderator |
|
|
Michel Cadot wrote on Wed, 30 January 2008 11:40 |
Let the other ones naturally raise.
|
Just in case you (Lenin) didn't understand that sentence, I'd like to say a few words about the issue: WHEN OTHERS can be used only in one-time-run examples (like - in my opinion - this one was). For anything more, it is better to use no exception handler at all than WHEN OTHERS as it successfully obfuscates a real reason why the error happened and, equally important, WHERE it happened (Oracle will show you exact code line).
Here's an example: this code doesn't do anything "smart", it is just used to illustrate what happens when you
a) do NOT use the WHEN OTHERS:SQL> declare
2 l_eno number;
3 begin
4 select empno into l_eno from emp;
5 end;
6 /
declare
*
ERROR at line 1:
ORA-01422: exact fetch returns more than requested number of rows
ORA-06512: at line 4
SQL> See? You know that there's something wrong there, and you know where it happened - at line 4.
b) use the WHEN OTHERS:SQL> declare
2 l_eno number;
3 begin
4 select empno into l_eno from emp;
5 exception
6 when others then null;
7 end;
8 /
PL/SQL procedure successfully completed. The WHEN OTHERS made it look perfect - no error at all! But, the procedure would fail and you wouldn't know that anything wrong happened.
A conclusion: be careful when you use WHEN OTHERS - it may do more harm than good.
|
|
|
|
|