I can't figure out why the code below is failing. I have my own version of the same script which returns the same error. I can't figure out in either case why the error persists.
This is the error:
raised CONSTRAINT_ERROR : main2.adb:32 index check failed
which is this line:
temp(i) := a(loop_high);
Anyone know what may be causing this?
with Text_IO;
with Ada.Integer_Text_IO;
procedure main2 is
use Text_IO;
use Ada.Integer_Text_IO;
type int_array is array(1..5) of integer;
tosort:int_array;
procedure merge (a:in out int_array; low,mid,high:in integer) is
temp: int_array;
choose1: boolean;
loop_low,loop_high:integer;
begin
loop_low:=low;
loop_high:=high;
for i in low..high loop
if (loop_low>mid) then choose1:=false;
elsif (loop_high>high) then choose1:=true;
else choose1:= a(loop_low)<a(loop_high);
end if; -- choose which side
if choose1 then -- choose from low side
temp(i):=a(loop_low);
loop_low:=loop_low+1;
else
temp(i):=a(loop_high); -- choose from high side
loop_high:=loop_high+1;
end if;
end loop;
a:=temp;
end merge;
procedure mergesort(a: in out int_array;low,high:integer) is
mid:integer;
begin
if low<high then
mid:= (high+low)/2;
mergesort(a,low,mid);
mergesort(a,mid+1,high);
merge(a,low,mid,high);
end if;
end mergesort;
begin
tosort := (171, 201, 397, 10, -381);
mergesort(tosort,1,5);
end main2;
I recommend compiling with -gnateE, which will give you more information for compiler-generated exceptions. In this specific case, it should tell you which value is outside of which range
Related
I have written following code in oracle pl/sql
create or replace procedure sorting_criteria(criteria in varchar)
as
begin
if(criteria='lowest price')
then
declare
p_name product.p_name%type;
cursor ptr is select p_name from product order by amount ASC;
begin
open ptr;
loop
fetch ptr into p_name;
exit when ptr%notfound;
dbms_output.put_line(p_name);
end loop;
close ptr;
end;
else if(criteria='highest price')
then
declare
p_name product.p_name%type;
cursor ptr is select p_name from product order by amount DESC;
begin
open ptr;
loop
fetch ptr into p_name;
exit when ptr%notfound;
dbms_output.put_line(p_name);
end loop;
close ptr;
end;
else
dbms_output.put_line('Enter valid criteria!');
end if;
end;
/
But it is giving following error: Error at line 35: PLS-00103: Encountered the symbol ";" when expecting one of the following: Please help
The ELSE-IF statement in PL/SQL has to be written as ELSIF. Otherwise, you should close the second IF with an other END IF; statement.
You can solve the issue by changing the ELSE IF at line 17 to an ELSIF
The answer by #GregorioPalamà correctly addresses your issues. But you can drastically reduce the workload by changing your thinking away from "If...then...else" to the "set of" and letting SQL do the work. In this case the only difference is sorting either ascending or descending on amount. The same effect can be achieved by sorting ascending on amount or minus amount; and SQL can make that decision. So you can reduce the procedure to validating the parameter and a single cursor for loop:
create or replace procedure sorting_criteria(criteria in varchar2)
as
cursor ptr(c_sort_criteria varchar2) is
select p_name
from product
order by case when c_sort_criteria = 'lowest price'
then amount
else -amount
end ;
begin
if criteria in ('lowest price', 'highest price')
then
for rec in ptr(criteria)
loop
dbms_output.put_line('Product: ' || rec.p_name );
end loop;
else
dbms_output.put_line('Enter valid criteria!');
end if;
end sorting_criteria;
/
See demo here. For demonstration purposed I added the amount to the dbms_output.
A couple notes:
While it is not incorrect using p_... as a column name, it is also
not a good idea. A very common convention (perhaps almost a
standard) to use p_... to indicate parameters. This easily leads to
confusion; confusion amongst developers is a bad thing.
IMHO it is a bug to name a local variable the same as a table
column name. While the compiler has scoping rules which one to use
it again leads to confusion. The statement "where table.name = name"
is always true, except when at least one of them is null, which possible could lead to updating/deleting every row in your table. In this
case p_name is both a column and a local variable.
How to solve the error, wrong number or types of arguments in call to '<', in the pl/sql code? This is my code:
DECLARE
A NUMBER;
BEGIN
IF :MOTOR_PRODUCTS.MOTOR_YEAR < TO_NUMBER(TO_CHAR(SYSDATE - 365, 'YYYY'))
THEN
A := SHOW_ALERT('ALERT_YEAR');
END IF;
END;
Thank you!
Here is the code
vResult VARCHAR2(200);
BEGIN
fvData:=TRIM(fvData);
IF SUBSTR(fvData,LENGTH(fvData)-1,1)<>'*' THEN
fvData:=fvData||'**';
END IF;
vResult:=SUBSTR(fvData,1,InStr(fvData,'^^') - 1);
fvData:=SUBSTR(fvData,InStr(fvData,'^^') + 3);
RETURN vResult;
END StringExtract;
/
I have tried entering different ways, with fvdata=365 but nothing happens, I have try entering small SQL like
select InStr(367,'^^^^') - 1
from dual;
but I can't figure out how to do this big function.
In an attempt to help you get this working take a look at the following code. I have left out the detail of your function so we don't complicate things but you should be able to just plug that back in.
DECLARE
inputValue VARCHAR2(200) := :inputValue; -- << this bind variable allows you to provide different input each you run the code
FUNCTION stringExtract(fvData varchar2) RETURN varchar2
IS
vResult VARCHAR2(200);
BEGIN
vResult := TRIM(fvData);
RETURN vResult;
END stringExtract;
BEGIN
DBMS_OUTPUT.PUT_LINE(LENGTH(inputValue));
DBMS_OUTPUT.PUT_LINE(LENGTH(stringExtract(inputValue)));
END;
Hopefully you can take that as a template and adapt to get your program running.
hi I wrote this code to create a procedure to return a Boolean value based on the if conditions but when I execute it I got this error:
ORA-06550: line 1, column 7:
PLS-00306: wrong number or types of arguments in call to 'DDPAY_SP'
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
06550. 00000 - "line %s, column %s:\n%s"
*Cause: Usually a PL/SQL compilation error.
*Action:
here is my procedure
create or replace procedure DDPAY_SP (
donor_id dd_donor.iddonor%type,
pldgstatus out dd_pledge.idstatus%type,
monthplan out dd_pledge.paymonths%type,
ret out boolean)
IS
begin
select idstatus, paymonths into
pldgstatus, monthplan from dd_pledge
where iddonor = donor_id ;
if (pldgstatus = 10 AND monthplan >0)
then ret:= true;
else
ret:= false;
end if;
end;
and this how I execute it
EXECUTE DDPAY_SP (308);
I didn't put much talk I hope it's clear enough for you
I read online it recommends me to check the naming also the data type which I did but nothing change
any ideas
If you don't need the second and third arguments you could declare those as variables in the procedure instead of arguments, as follows:
CREATE OR REPLACE PROCEDURE DDPAY_SP(DONOR_ID IN DD_DONOR.IDDONOR%TYPE,
RET OUT BOOLEAN)
IS
nPayment_count NUMBER;
BEGIN
SELECT COUNT(*)
INTO nPayment_count
FROM DD_PLEDGE p
WHERE p.IDDONOR = DONOR_ID AND
p.IDSTATUS = 10 AND
p.PAYMONTHS > 0;
IF nPayment_count > 0 THEN
RET := TRUE;
END IF;
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('DD_PAY - exception: ' || SQLCODE || ' : ' || SQLERRM);
RAISE;
END DDPAY_SP;
I've included an example of an EXCEPTION handler at the end of DD_PAY. It's always a good idea to include at least this minimal handler so that in the event an exception occurs you'll get some indication of where the problem lies.
Because this procedure returns a BOOLEAN value, and BOOLEANs cannot (to the best of my knowledge) be used from SQL*Plus, you'll have to invoke it from a PL/SQL block, as follows:
DECLARE
bRetval BOOLEAN;
BEGIN
DD_PAY(308, bRetval);
DBMS_OUTPUT.PUT_LINE('Returned value is ' ||
CASE bRetval
WHEN TRUE THEN 'TRUE'
ELSE 'FALSE'
END);
END;
Give that a try.
EDIT: rewrote procedure based on further information from later comments.
Share and enjoy.
I have strictly optimization problem. where in my PACKAGE I should place CONSTANT variables when procedure/function is being called many times ?
Let's look at this:
CREATE OR REPLACE PACKAGE WB_TEST IS
PROCEDURE TEST;
END WB_TEST;
CREATE OR REPLACE PACKAGE BODY WB_TEST IS
FUNCTION PARSER(IN_PARAM IN VARCHAR2) RETURN VARCHAR2 IS
LC_MSG CONSTANT VARCHAR2(80) := 'Hello USERNAME! How are you today?';
LC_PARAM CONSTANT VARCHAR2(10) := 'USERNAME';
BEGIN
RETURN REPLACE(LC_MSG, LC_PARAM, IN_PARAM);
END PARSER;
PROCEDURE TEST IS
BEGIN
FOR I IN 1 .. 1000 LOOP
DBMS_OUTPUT.PUT_LINE(PARSER(TO_CHAR(I)));
END LOOP;
END TEST;
BEGIN
DBMS_OUTPUT.ENABLE(1000000);
END WB_TEST;
/
Or is better to do something like that:
CREATE OR REPLACE PACKAGE WB_TEST IS
PROCEDURE TEST;
END WB_TEST;
CREATE OR REPLACE PACKAGE BODY WB_TEST IS
GC_MSG CONSTANT VARCHAR2(80) := 'Hello USERNAME! How are you today?';
GC_PARAM CONSTANT VARCHAR2(10) := 'USERNAME';
FUNCTION PARSER(IN_PARAM IN VARCHAR2) RETURN VARCHAR2 IS
BEGIN
RETURN REPLACE(GC_MSG, GC_PARAM, IN_PARAM);
END PARSER;
PROCEDURE TEST IS
BEGIN
FOR I IN 1 .. 1000 LOOP
DBMS_OUTPUT.PUT_LINE(PARSER(TO_CHAR(I)));
END LOOP;
END TEST;
BEGIN
DBMS_OUTPUT.ENABLE(1000000);
END WB_TEST;
It is extremely unlikely to matter from a performance standpoint. The code the PL/SQL compiler generates should be identical in both cases-- the constants will almost certainly get compiled inline where they are referenced.
The only reason to prefer one over the other would be code clarity and variable scoping. If the constants are really local to the PARSER function-- if they aren't likely to be useful to other methods in the package, they ought to be declared as part of the function. If, on the other hand, they are likely to be useful to other methods in the package, they ought to be declared as part of the package body. If they are likely to be useful to methods outside the package, they ought to be declared as part of the package specification.