ORA-01722: invalid number Error - 1 - oracle

I'm stuck and can't see what the problem is.
I created a procedure with some logic stuff and it compiled successfully, but when I call it in a trigger on my table, it fails with ORA-01722: invalid number.
Any help would be gratefully received.
Here is the procedure:
create or replace Procedure Check_Plants_Fields(
field_id IN number ,
farmer_name IN varchar2,
planting_date IN date DEFAULT sysdate,
planting_amount IN number,
plant_type IN number)
IS
l_plant_type XXLA_PLANTS_TYPE.PLANT_TYPE%type;
l_number_of_months XXLA_PLANTS_SUPPLIERS.NUMBER_MONTHS_TO_CUT%type;
cursor c1 is
SELECT PLANT_TYPE , AMOUNT_
FROM XXLA_PLANTS_TYPE
WHERE PLANT_ID = plant_type;
cursor c2 is
SELECT to_number(MOD(Round(DBMS_RANDOM.Value(1, 8)), 9) + 1)
FROM DUAL;
BEGIN
open c1;
open c2;
fetch c2 into l_number_of_months;
if c1 %notfound then
close c1;
dbms_output.put_line('You dont have this type, please supply it to your store . ' || ' ' || 'thanx.');
end if;
for i in (SELECT PLANT_TYPE , AMOUNT_
FROM XXLA_PLANTS_TYPE
WHERE PLANT_ID = plant_type)
LOOP
if i.AMOUNT_ < 20 then
dbms_output.put_line(i.AMOUNT_ ||' AMOUNT_: '|| i.AMOUNT_);
UPDATE XXLA_PLANTS_SUPPLIERS
SET supplier_id = supplier_id_seq.nextval;
INSERT INTO XXLA_PLANTS_SUPPLIERS
(supplier_id, supplier_name, number_months_to_cut, date_,amount, price_in_KG)
VALUES (supplier_id_seq.nextval, 'Benefits etc',l_number_of_months ,sysdate+1, 80 + i.AMOUNT_,'500$');
end if;
END LOOP i;
commit;
close c2;
EXCEPTION
WHEN OTHERS THEN
raise_application_error(-20001,'An error was encountered,- '||SQLCODE||' -ERROR- -->'||SQLERRM );
END;
And here is the trigger:
create or replace TRIGGER xxbefor_insert_plants
BEFORE INSERT ON XXLA_PLANT_FIELDS
FOR EACH ROW
BEGIN
Check_Plants_Fields(:NEW.field_id, :NEW.farmer_name, :NEW.planting_date, :NEW.planting_amount, :NEW.plant_type);
END;
Here is the insert that executes the trigger that calls the procedure, but it errors when I run it.
INSERT INTO XXLA_PLANT_FIELDS
(field_id, FARMER_NAME,planting_date,planting_amount,plant_type )
VALUES
(4, 'Test1',sysdate,8,1 (because this parameter it should work its under 20 ));

ORA-01722: invalid number is quite a simple error to understand. It means you are attempting to cast a string to a number datatype but the operation fails because the string contains non-numeric characters.
So what this means is that somewhere in your procedure you have a implicit type conversion. You haven't provided the description of the tables so we can't tell you where the problem happens. You'll have to discover it for yourself.
Two places where it might be:
WHERE PLANT_ID = plant_type if XXLA_PLANTS_TYPE.PLANT_ID is not
numeric
VALUES (... '500$'); if
XXLA_PLANTS_SUPPLIERS.PRICE_IN_KG is not numeric
Incidentally, if you removed that pointless exception handler you would get the default error stack. That would tell you the starting line number of the failing statement, which would really remove a lot of the guesswork from the exercise.

Related

PLS-00103: Encountered the symbol "IS" when expecting one of the following: := . ( # % ; not null range default character

I am facing this error:
LINE/COL ERROR
-------- -----------------------------------------------------------------
4/11 PLS-00103: Encountered the symbol "IS" when expecting one of the
following:
:= . ( # % ; not null range default character
My package is:
CREATE OR REPLACE PACKAGE BODY EMP_PK AS
PROCEDURE INSERT_TR(EMPNO EMP_20171250.EMPNO%TYPE,ENAME EMP_20171250.ENAME%TYPE,SAL EMP_20171250.SAL%TYPE) IS
INSERT_ERROR EXCEPTION;
CRUSOR C1 IS INSERT INTO EMP_20171250(EMPNO,ENAME,SAL) VALUES(EMPNO,ENAME,SAL);
BEGIN
IF(C1%FOUND) THEN
DBMS_OUTPUT.PUT_LINE('RECORD INSERTED');
ELSE
RAISE INSERT_ERROR;
END IF;
EXCEPTION
WHEN INSERT_ERROR THEN
DBMS_OUTPUT.PUT_LINE('ERROR WHILE RECORD INSERTION');
END INSERT_TR;
END EMP_PK;
it is not CRUSOR but CURSOR
cursor can't contain INSERT statement; it is a SELECT
you are checking whether cursor returned something, but - you never opened it nor fetched from it so it is pretty much useless
insert_error looks like there was an error while inserting a row, but - you are actually raising it if cursor didn't return anything
Basically, you don't need a cursor at all. Such a procedure would do:
PROCEDURE insert_tr (p_empno emp_20171250.empno%TYPE,
p_ename emp_20171250.ename%TYPE,
p_sal emp_20171250.sal%TYPE)
IS
BEGIN
INSERT INTO emp_20171250 (empno, ename, sal)
VALUES (p_empno, p_ename, p_sal);
END insert_tr;
If insert fails, Oracle will raise an exception anyway so - yes, you can handle it/them if you want.
Also, it is good to distinguish parameter names from column names; for example, precede their names with a p_ (as I did).

Ignore lines that causes errors

I have a big Oracle script with thousands of package call inside a BEGIN - END;
Is there a way to ignore the lines that causes error and continue executing the next lines? Some sort of "On Error Resume Next" in vb.
If you have only one BEGIN END section, then you can use EXCEPTION WHEN OTHERS THEN NULL.
SQL> declare
v_var pls_integer;
begin
select 1 into v_var from dual;
-- now error
select 'A' into v_var from dual;
exception when others then null;
end;
SQL> /
PL/SQL procedure successfully completed.
SQL> declare
v_var pls_integer;
begin
select 1 into v_var from dual;
-- now error
select 'A' into v_var from dual;
--exception when others then null;
end;
/
declare
*
ERROR at line 1:
ORA-06502: PL/SQL: numeric or value error: character to number conversion error
ORA-06512: at line 6
SQL>
The whole concept of "ignore errors" is a bug, and a lie if any errors occur. That is not to say you cannot trap errors and continue processing, just that you MUST handle the errors. For example, assume the use case: "Data has been loaded into a stage table from multiple .csv files. Now load into the tables A and Table B according to ....".
create procedure
Load_Tables_A_B_from_Stage(process_message out varchar2)
is
Begin
For rec in (select * from stage)
loop
begin
insert into table_a (col1, col2)
values (rec.col_a1, col_a2);
insert into table_b (col1, col2)
values (rec.col_b1, col_b2);
exception
when others then null;
end;
end loop;
process_message := 'Load Tables A,B Complete';
end ;
Now suppose a user created the a .csv file entered "n/a" in numeric columns where there was no value or the value was unknown. The result of this all too common occurrence is all such rows were not loaded, but you have no way to know that until the user complains their data was not loaded even though you told them it was. Further you have no way of determining the problem.
A much better approach is to "capture and report".
create procedure
Load_Tables_A_B_from_Stage(process_message out varchar2)
is
load_error_occurred boolean := False;
Begin
For rec in (select * from stage)
loop
begin
insert into table_a (col1, col2)
values (rec.col_a1, rec.col_a2);
exception
when others then
log_load_error('Load_Tables_A_B_from_Stage', stage_id, sqlerrm);
load_error_occurred := True;
end;
begin
insert into table_b (col1, col2)
values (rec.col_b1, rec.col_b2);
exception
when others then
log_load_error('Load_Tables_A_B_from_Stage', stage_id, sqlerrm);
load_error_occurred := True;
end;
end loop;
if load_error_occurred then
process_message := 'Load Tables A,B Complete: Error(s) Detected';
else
process_message := 'Load Tables A,B Complete: Successful No Error(s)';
end if;
end Load_Tables_A_B_from_Stage ;
Now you have informed the user of the actual status, and where you are contacted you can readily identify the issue.
User here is used in the most general sense. It could mean a calling routine instead of an individual. Point is you do not have to terminate your process due to errors but DO NOT ignore them.
I don't think there is any magic one-liner that will solve this.
As others have, use a editor to automate the wrapping of each call within a BEGIN-EXCEPTION-END block might be quicker/easier.
But, if feel a little adventurous, or try this strategy:
Let's assume you have this:
BEGIN
proc1;
proc2;
proc3;
.
.
.
proc1000;
END;
You could try this (untested, uncompiled but might give you an idea of what to try):
DECLARE
l_progress NUMBER := 0;
l_proc_no NUMBER := 0;
e_proc_err EXCEPTION;
-- A 'runner' procedure than manegrs the counters and runs/skips dpending on these vals
PROCEDURE run_proc ( pname IN VARCHAR2 ) IS
BEGIN
l_proc_no := l_proc_no + 1;
IF l_proc_no >= l_progress
THEN
-- log 'Running pname'
EXECUTE IMMEDIATE 'BEGIN ' || pname || '; END;' ;
l_progress := l_progress + 1;
ELSE
-- log 'Skipping pname'
END IF;
EXCEPTION
WHEN OTHERS THEN
-- log 'Error in pname'
l_progress := l_progress + 1;
RAISE e_proc_err;
END;
BEGIN
l_progress := 0;
<<start>>
l_proc_no := 0;
run_proc ( 'proc1' );
run_proc ( 'proc2' );
run_proc ( 'proc3' );
.
.
run_proc ( 'proc1000' );
EXCEPTION
WHEN e_proc_err THEN
GOTO start;
WHEN OTHERS THEN
RAISE;
END;
The idea here is to add a 'runner' procedure to execute each procedure dynamically and log the run, skip, error.
We maintain a global count of the current process number (l_proc_no) and overall count of steps executed (l_progress).
When an error occurs we log it, raise it and let it fall into the outer blocks EXCEPTION handler where it will restart via an (evil) GOTO.
The GOTO is placed such that the overall execution count is unchanged but the process number is reset to 0.
Now when the run_proc is called it sees that l_progress is greater than l_proc_no, and skips it.
Why is this better than simply wrapping a BEGIN EXCEPTION END around each call?
It might not be, but you make a smaller change to each line of code, and you standardise the logging around each call more neatly.
The danger is a potential infinite loop which is why I specify e_proc_err to denote errors within the called procedures. But it might need tweaking to make it robust.

I am getting an error message in Oracle SQL stored procedure

I am trying the following code
CREATE OR REPLACE PROCEDURE sal2
AS
BEGIN
SELECT sal
FROM emp
END
And I'm getting this error
Error at line 7: PLS-00103: Encountered the symbol "end-of-file" when expecting one of the following:
( begin case declare end exception exit for goto if loop mod
null pragma raise return select update while with
<< continue close current delete fetch lock
insert open rollback savepoint set sql execute commit forall
merge pipe purge
5. from emp
6. return 1
7. END
What I want to do is to get a sal column from emp table.
There are multiple issues with code as following;
create or replace procedure sal2
AS
Lv_var number; -- added variable for holding select value
BEGIN
select sal
Into lv_var -- into is needed in select
from emp; -- you missed this semicolon
-- you must use where clause as into variable can hold single value
-- so you must restrict this query to return only 1 record.
END; -- you missed this semicolon
/
Cheers!!
First you have to put the semicolon at the end of each line and after the END keyword. Then the SELECT statement is also wrong you have to load the result in a variable.
Here is the solution for multiple rows.
CREATE OR REPLACE PROCEDURE sal2
AS
CURSOR c_salaries IS SELECT salary FROM employees;
TYPE t_salaries IS TABLE OF c_salaries%rowtype INDEX BY BINARY_INTEGER;
v_salaries t_salaries;
BEGIN
OPEN c_salaries;
FETCH c_salaries BULK COLLECT INTO v_salaries;
CLOSE c_salaries;
END;
And one for a single row result.
CREATE OR REPLACE PROCEDURE sal2
AS
v_salary employees.salary%rowtype;
BEGIN
SELECT salary INTO v_salary
FROM employees WHERE employee_id = 100;
END;

Why are none of my conditions being met in this proc?

So i have a stored procedure (that's been watered down below for demo purposes) that aren't passing any conditions and thus aren't inserting/passing any values into my table. I've tried converting the varchar/string that is being passed in by Java to a number but nothing is working. Below is my 'simplified code'
Create or Replace Procedure SAMPLE(rValue IN VARCHAR)
IS
v_Max value.value%type;
v_forecast value.value%type;
BEGIN
--
SELECT BUFFER_MAX_VALUE
INTO v_MAX
FROM look_up;
--
EXCEPTION
WHEN no_data_found
THEN SELECT 0
INTO v_forecast
FROM DUAL;
--
IF to_Number(rValue) < 0 OR to_Number(rValue) > v_MAX)
THEN
dbms_output.put_line('IF1 Works');
insert into value(value_id, value)
values(1, rValue);
ELSIF rValue is null OR to_Number(rValue) = 0
THEN
dbms_output.put_line('IF1A ONLY Works');
END IF;
ELSE
insert into value(value_id, value)
values(1, v_forecast);
dbms_output.put_line('IF1 ELSE ONLY Works');
END SAMPLE;
i tried passing the following in:
BEGIN
SAMPLE('-7');
END;
If the first SELECT BUFFER_MAX_VALUE returns anything, nothing else will be executed because you put absolutely everything into the EXCEPTION section. If you meant to handle that statement only, you should have enclosed it into its own BEGIN-END block, such as
create procedure ...
begin
-- its own begin starts now
begin
select buffer_max_value into v_max
from look_up;
exception
when no_data_found then
-- do something here
end;
-- its own end ends now
-- put the rest of your code here
end;
By the way, does LOOK_UP table contain no rows or only one row, always? Because, as SELECT you wrote contains no WHERE clause, it might raise TOO_MANY_ROWS (which you should also handle).
You declared rValue as VARCHAR2, and then apply TO_NUMBER to it. Why don't you declare it to be a NUMBER, instead? Because, nothing prevents you from passing, for example, 'XYZ' to the procedure, and then TO_NUMBER will miserably fail with the INVALID NUMBER error.
[EDIT: some more exception handling]
EXCEPTION section handles all exceptions that happen in that BEGIN-END block, no matter how many SELECT statements you have. Though, you won't know which one failed, unless you include a little bit of additional (simple) programming.
Note that this is just for showing what I meant; don't handle errors with DBMS_OUTPUT (as, most probably, nobody will see it), and rarely you'd want to handle errors with WHEN OTHERS.
create procedure ...
l_position number;
begin
l_position := 1;
select ... into ... from ...;
l_position := 2;
select ... into ...
exception
when others then
dbms_output.put_line('Error on position ' || l_position ||' '|| sqlerrm);
raise;
end;
As far as I can tell, you wanted the exception section to trap the situation where there is nothing in the lookup table. In that case, you set v_forecast and then continue. That means you need to put the select inside its own block.
I also avoiding multiple to_number calls by setting a constant.
I got rid of the unnecessary select from dual.
I also really really hope that you do not have a table named VALUE with a column named VALUE. Choose more meaningful names.
See how this works for you.
CREATE OR REPLACE PROCEDURE sample (rvalue IN VARCHAR2)
IS
c_rvalue CONSTANT NUMBER := rvalue;
v_max VALUE.VALUE%TYPE;
v_forecast VALUE.VALUE%TYPE;
BEGIN
BEGIN
SELECT buffer_max_value INTO v_max FROM look_up;
EXCEPTION
WHEN NO_DATA_FOUND
THEN
v_forecast := 0;
END;
IF c_rvalue < 0 OR c_rvalue > v_max
THEN
DBMS_OUTPUT.put_line ('IF1 Works');
INSERT INTO VALUE (value_id, VALUE)
VALUES (1, rvalue);
ELSIF c_rvalue IS NULL OR c_rvalue = 0
THEN
DBMS_OUTPUT.put_line ('IF1A ONLY Works');
ELSE
INSERT INTO VALUE (value_id, VALUE)
VALUES (1, v_forecast);
DBMS_OUTPUT.put_line ('IF1 ELSE ONLY Works');
END IF;
END sample;

ORACLE PL/SQL Programming Trigger problems

I'm trying to figure out a simple ORACLE PL/SQL programming problem and I'm having some difficulties with it.
I have to make a trigger that catches inserts into a table, and if the location attribute of the new tuple getting into that table doesn't exist in the database, I need to throw a warning message and insert that new location into another table.
What I have now so far -
CREATE TRIGGER sightTrigger
AFTER INSERT ON SIGHTINGS
FOR EACH ROW
DECLARE
ct INTEGER;
BEGIN
SELECT COUNT(*)
INTO ct
FROM SIGHTINGS
WHERE SIGHTINGS.location <> :NEW.location;
IF ct > 0 THEN
RAISE_APPLICATION_ERROR('WARNING SIGN' || :NEW.location ||' does not exist in the database');
INSERT INTO FEATURES(LOCATION, CLASS, LATITUDE, ...)
VALUES (:NEW.LOCATION, 'UNKNOWN', ...);
END IF;
END;
I'm getting an error, "PLS-00306: wrong number of types of arguments in call to 'RAISE_APP_ERROR'. Could somebody tell me what's wrong? thank you
Try this:
RAISE_APPLICATION_ERROR(
-20001,
'WARNING SIGN' || :NEW.location || 'does not exist in the database'
);
Your RAISE_APPLICATION_ERROR takes two arguments (this is from Oracle docs): where error_number is a negative integer in the range -20000 .. -20999 and message is a character string up to 2048 bytes long.

Resources