I want to retrieve database constants through query in front end to fill this constant string in DropDownList.
I have tried following query
select pr_Package.constant_String from dual;
Suggestions are welcome.
You can't reference a packaged constant directly in a SQL statement.
You can add a function to your package that returns the constant and call that function from SQL. Something like this will work (though you may want to consider moving the constant to the package body rather than the package specification once you have a function to return the data).
create or replace package pkg_const
as
some_constant number;
function get_constant
return number;
end;
create or replace package body pkg_const
as
function get_constant
return number
is
begin
return some_constant;
end;
end;
select pkg_const.get_constant from dual;
Related
I have a task to use cursor to write a function that receives a movie title and then returns pay of actors involved in this movie.
I wrote something like this:
DELIMITER $$
CREATE FUNCTION getPay(movieTitle varchar(90))
RETURNS int;
BEGIN
DECLARE P int;
DECLARE done int DEFAULT FALSE;
DECLARE payCursor CURSOR FOR
(SELECT A.pay FROM actors A JOIN movie M ON M.id=A.movie WHERE M.title=movieTitle);
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done=1;
OPEN payCursor;
loop_read : LOOP
FETCH payCursor INTO P;
IF done THEN
LEAVE loop_read;
END IF;
RETURN P;
END LOOP;
CLOSE payCursor;
END $$
DELIMITER ;
It's not a secret it's not working. I don't know how to return a set, moreover as I've read it's not possible in MariaDB. I tried to create temporary table but it's not good solution if you want to use this function several times. Also I would like to use this function in another task where I have to write a procedure to pay all the actors. I'm not sure I got the idea of cursors.
That function seems to be getting one (any one) row from the query. This would replace the function:
SELECT A.pay
FROM actors A
JOIN movie M ON M.id=A.movie
WHERE M.title=movieTitle)
LIMIT 1;
Or, since it is a function, get rid of the cursor, and have only that in the function.
I have a package working fine in 11g version.
But when I deploy the same package in 19c version, the behavior is different.
PFB the description.
Package specification has an cursor and created a table type with cursor%rowtype.
Having a pipelined function which returns the table type.
Using the function with table clause
select * from table(function)
so that the return value can act as a table and I can read the result with column names.
In 11g, the function is returning the column headers same as the cursor column names.
But in 19c, the function is returning column headers like 'Attr_1, Attr_2, etc'.
I need the function to return the column headers as the cursor columns names.
Note: Code can't be shared as it is very sensitive.
Sample:
PFB the sample.
Create table tb_test (id number, description varchar2 (50));
create or replace package pkg_test is
cursor cur_test is
select *
from tb_test
where 1=2;
type typ_cur_test is table of cur_test%rowtype;
function fn_test(p_rows in number) return typ_cur_test pipelined;
end;
create or replace package body pkg_test is
function fn_test(p_rows in number) return typ_cur_test pipelined as
l_tab typ_cur_test := cur_typ_test();
begin
for i in 1..p_rows loop l_tab.extend;
l_tab(i).Id := i;
l_tab(i). Description := 'test';
pipe roe(l_tab(i));
end loop;
return ;
end;
end pkg_test;
Select * from table(pkg_test.fn_test(2));
In 11g, the above select gives column headers as "id, description", but in 19c i am getting as "ATTR_1, ATTR_2".
Please help.
Solution for your issue could be:
create or replace package pkg_test is
cursor cur_test is
select *
from tb_test
where 1=2;
type typ_cur_test is table of {tb_test}%rowtype;
function fn_test(p_rows in number) return typ_cur_test pipelined;
end;
Was able to reproduce the explained behavior. On 19c -> Attr_1, Attr_2 on 11 -> ID, Description
Workaround I found is use base table/view%rowtype instead of cursor%rowtype.
I was trying to create a function that given a customer name, get the total balance of that customer's accounts from the account table(A#, CNAME, BAL).
When compiling in command, I got errors:
line "SELECT SUM(bal) INTO total_a_bal FROM account" ignored
and line "WHERE account.cname = v_acname" SQL cmd not properly ended.
Please help correct the errors. Any help would be greatly appreciated!
My function is :
CREATE OR REPLACE FUNCTION totbal
(v_acname IN account.cname%type)
RETURN NUMBER
IS
total_a_bal NUMBER;
BEGIN
SELECT SUM(bal) INTO total_a_bal FROM account
group by account.cname
WHERE account.cname = v_acname;
RETURN total_a_bal;
END;
/
This may not be the only problem with your function, but the WHERE clause always precedes the GROUP BY clause in a SQL query. Hence, your function should look like this:
CREATE OR REPLACE FUNCTION totbal
(v_acname IN varchar2) -- a type should follow IN, e.g. varchar2
RETURN NUMBER
IS
total_a_bal NUMBER;
BEGIN
SELECT SUM(bal) INTO total_a_bal
FROM account
WHERE account.cname = v_acname; -- WHERE always precedes GROUP BY
GROUP BY account.cname
RETURN total_a_bal;
END;
Oracle not only works with the parameter definition "account.cname%type" that is preferred method. What it does is to bind the parameter definition to the column in the database. If the column definition is changed the procedure automatically gets the changed.
This concept of defining in terms of data base columns can (and perhaps should) be extended into the variables and return types of the procedure/function itself.
This function then becomes:
CREATE OR REPLACE FUNCTION totbal
(v_acname IN account.cname%type)
RETURN account.bal%type
IS
total_a_bal account.bal%type;
BEGIN
SELECT SUM(bal) INTO total_a_bal FROM account
group by account.cname
WHERE account.cname = v_acname;
RETURN total_a_bal;
END;
I'm designing a function that is part of a larger package. The function is intended to take a District Code and return a collection of unique IDs for 10-15 stores that are assigned to that district. The function is intended to return a collection that can be queried like a table, i.e., using the TABLE function in a SQL statement.
I've created the following Types:
Schema Level type:
create or replace TYPE HDT_CORE_ORGIDS AS TABLE OF CHAR(20);
and a Type inside the Package
TYPE CORE_ORGIDS IS TABLE OF CHAR(20) INDEX BY BINARY_INTEGER;
Here's the function code:
FUNCTION FindDistrictOrgs(
ParamOrgCode VARCHAR2
)
RETURN HDT_CORE_ORGIDS
AS
ReturnOrgs HDT_CORE_ORGIDS := HDT_CORE_ORGIDS();
FDOTemp HDT_CORE_MAIN.CORE_ORGIDS;
i BINARY_INTEGER := 0;
CURSOR FDOCurr IS
SELECT org.id AS OrgID
FROM tp2.tpt_company org
WHERE LEVEL = 2
START WITH org.name = ParamOrgCode
CONNECT BY PRIOR org.id = org.parent_id;
BEGIN
OPEN FDOCurr;
LOOP
i := i +1;
FETCH FDOCurr INTO FDOTemp(i);
EXIT WHEN FDOCurr%NOTFOUND;
END LOOP;
IF FDOTemp.EXISTS(FDOTemp.FIRST) THEN
ReturnOrgs.EXTEND(FDOTemp.LAST);
FOR x IN FDOTemp.FIRST .. FDOTemp.LAST LOOP
ReturnOrgs(x) := FDOTemp(x).OrgID;
END LOOP;
END IF;
CLOSE FDOCurr;
RETURN ReturnOrgs;
END FindDistrictOrgs ;
I'm getting the PLS-00487:Invalid Reference to variable 'CHAR' at the line:
ReturnOrgs(x) := FDOTemp(x).OrgID;
I've double-checked at the value returned by the SQL (the org.id AS OrgID) is of the CHAR(20 BYTE) datatype.
So...what's causing the error?
Any help is appreciated! :)
OrgID is the alias you gave the column in your cursor, it has no meaning to the collection. Since both collections are of simple types you should just be doing:
ReturnOrgs(x) := FDOTemp(x);
The syntax you're using is implying FDOTemp is a collection of objects and you're trying to reference the OrgID attribute of an object; but since CHAR isn't an object type, this errors. The error message even makes some sense when viewed like that, though it's not terribly helpful if you don't already know what's wrong... and not entirely helpful when you do.
Incidentally, you could use a bulk collect to populate the collection without the cursor or loops, or the extra collection:
SELECT org.id
BULK COLLECT INTO ReturnOrgs
FROM tp2.tpt_company org
WHERE LEVEL = 2
START WITH org.name = ParamOrgCode
CONNECT BY PRIOR org.id = org.parent_id;
RETURN ReturnOrgs;
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.