Developer

Sometimes a variables table is better than hard coding into a 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.

Editor's Picks