Sometimes a variables table is better than hard coding into a package
By Rex Baldazo, Special to ZDNet Asia
Thursday, December 06, 2007 01:39 PM
Thursday, December 06, 2007 01:39 PM
When writing PL/SQL packages, there are times where it's better to store a variable in a table instead of coding it into the package.
When writing PL/SQL packages, there are times where it's better to store a variable in a table instead of coding it into the package. It's most useful for a variable that you might want to change fairly often. If you put such a variable directly in the package (either the spec or body), the only way to modify it is to edit that package and recompile. The recompile can become problematic; if your application is still running then a user's session might have that package locked and it prevents compilation. It happens to me all the time when maintaining somebody else's application.
Now I store certain variables in a table instead. All it takes to change the variable (and thus the application's behavior) is a SQL update and commit to that table.
The variable table is pretty straightforward. I use two fields: a name and a value:
CREATE TABLE "VARIABLES"
( "NAME" VARCHAR2(60 BYTE) NOT NULL,
"VALUE" VARCHAR2(255 BYTE),
CONSTRAINT "VARIABLES_PK" PRIMARY KEY ("NAME")
Now all you need is a function to return the values from that table:
create or replace
function get_variable (p_name variables.name%type)
return variables.value%type is
cursor cur_variables is
select value
from variables
where name = p_name;
v_value variables.value%type;
begin
for v_rec in cur_variables loop
v_value:= v_rec.value;
end loop;
return v_value;
end;
In your PL/SQL package, you might use a variable like this:
v_server_name variables.value%type:= get_variable('server_name');
This really simple little trick can make things so much easier for you. I store pretty much everything I think may change often in such an external table.
Play video
» Blades for superior performance
There are currently no comments for this post.