Introduction to PL/SQL
- What is so great about PL/SQL anyway?
- PL/SQL Architecture
- Overview of PL/SQL Elements
- My Utopian Development Environment
What is so great about PL/SQL anyway?
PL/SQL is a procedural extension of SQL, making it extremely simple to write procedural code that includes SQL as if it were a single language. In comparison, most other programming languages require mapping data types, preparing statements and processing result sets, all of which require knowledge of specific APIs.
The data types in PL/SQL are a super-set of those in the database, so you rarely need to perform data type conversions when using PL/SQL. Ask your average Java or .NET programmer how they find handling date values coming from a database. They can only wish for the simplicity of PL/SQL.
When coding business logic in middle tier applications, a single business transaction may be made up of multiple interactions between the application server and the database. This adds a significant overhead associated with network traffic. In comparison, building all the business logic as PL/SQL in the database means client code needs only a single database call per transaction, reducing the network overhead significantly.
Oracle is a multi-platform database, making PL/SQL and incredibly portable language. If your business logic is located in the database, you are protecting yourself from operating system lock-in.
Programming languages go in and out of fashion continually. Over the last 35+ years Oracle databases have remained part of the enterprise landscape. Suggesting that any language is a safer bet than PL/SQL is rather naive. Placing your business logic in the database makes changing your client layer much simpler if you like to follow fashion.
Centralizing application logic enables a higher degree of security and productivity. The use of Application Program Interfaces (APIs) can abstract complex data structures and security implementations from client application developers, leaving them free to do what they do best.
The PL/SQL language is actually made up of two distinct languages. Procedural code is executed by the PL/SQL engine, while SQL is sent to the SQL statement executor.
For the most part, the tight binding between these two languages make PL/SQL look like a single language to most developers.
Overview of PL/SQL Elements
Blocks are the organizational unit for all PL/SQL code, whether it is in the form of an anonymous block, procedure, function, trigger or type. A PL/SQL block is made up of three sections (declaration, executable and exception), of which only the executable section is mandatory.
[DECLARE -- delarations] BEGIN -- statements [EXCEPTION -- handlers END;
Based on this definition, the simplest valid block is shown below, but it doesn't do anything.
BEGIN NULL; END;
The optional declaration section allows variables, types, procedures and functions do be defined for use within the block. The scope of these declarations is limited to the code within the block itself, or any nested blocks or procedure calls. The limited scope of variable declarations is shown by the following two examples. In the first, a variable is declared in the outer block and is referenced successfully in a nested block. In the second, a variable is declared in a nested block and referenced from the outer block, resulting in an error as the variable is out of scope.
DECLARE l_number NUMBER; BEGIN l_number := 1; BEGIN l_number := 2; END; END; / PL/SQL procedure successfully completed. BEGIN DECLARE l_number NUMBER; BEGIN l_number := 1; END; l_number := 2; END; / l_number := 2; * ERROR at line 8: ORA-06550: line 8, column 3: PLS-00201: identifier 'L_NUMBER' must be declared ORA-06550: line 8, column 3: PL/SQL: Statement ignored SQL>
The main work is done in the mandatory executable section of the block, while the optional exception section is where all error processing is placed. The following two examples demonstrate the usage of exception handlers for trapping error messages. In the first, there is no exception handler so a query returning no rows results in an error. In the second the same error is trapped by the exception handler, allowing the code to complete successfully.
DECLARE l_date DATE; BEGIN SELECT SYSDATE INTO l_date FROM dual WHERE 1=2; -- For zero rows END; / DECLARE * ERROR at line 1: ORA-01403: no data found ORA-06512: at line 4 DECLARE l_date DATE; BEGIN SELECT SYSDATE INTO l_date FROM dual WHERE 1=2; -- For zero rows EXCEPTION WHEN NO_DATA_FOUND THEN NULL; END; / PL/SQL procedure successfully completed. SQL>
Variables and Constants
Variables and constants must be declared for use in procedural and SQL code, although the datatypes available in SQL are only a subset of those available in PL/SQL. All variables and constants must be declared before they are referenced. The declarations of variables and constants are similar, but constant definitions must contain the CONSTANT keyword and must be assigned a value as part of the definition. Subsequent attempts to assign a value to a constant will result in an error. The following example shows some basic variable and constant definitions, along with a subsequent assignment of a value to a constant resulting in an error.
DECLARE l_string VARCHAR2(20); l_number NUMBER(10); l_con_string CONSTANT VARCHAR2(20) := 'This is a constant.'; BEGIN l_string := 'Variable'; l_number := 1; l_con_string := 'This will fail'; END; / l_con_string := 'This will fail'; * ERROR at line 10: ORA-06550: line 10, column 3: PLS-00363: expression 'L_CON_STRING' cannot be used as an assignment target ORA-06550: line 10, column 3: PL/SQL: Statement ignored SQL>
In addition to standard variable declarations used within SQL, PL/SQL allows variable datatypes to match the datatypes of existing columns, rows or cursors using the %TYPE and %ROWTYPE qualifiers, making code maintenance much easier. The following code shows each of these definitions in practice.
DECLARE -- Specific column from table. l_username all_users.username%TYPE; -- Whole record from table. l_all_users_row all_users%ROWTYPE; CURSOR c_user_data IS SELECT username, created FROM all_users WHERE username = 'SYS'; -- Record that matches cursor definition. l_all_users_cursor_row c_user_data%ROWTYPE; BEGIN -- Specific column from table. SELECT username INTO l_username FROM all_users WHERE username = 'SYS'; DBMS_OUTPUT.put_line('l_username=' || l_username); -- Whole record from table. SELECT * INTO l_all_users_row FROM all_users WHERE username = 'SYS'; DBMS_OUTPUT.put_line('l_all_users_row.username=' || l_all_users_row.username); DBMS_OUTPUT.put_line('l_all_users_row.user_id=' || l_all_users_row.user_id); DBMS_OUTPUT.put_line('l_all_users_row.created=' || l_all_users_row.created); -- Record that matches cursor definition. OPEN c_user_data; FETCH c_user_data INTO l_all_users_cursor_row; CLOSE c_user_data; DBMS_OUTPUT.put_line('l_all_users_cursor_row.username=' || l_all_users_cursor_row.username); DBMS_OUTPUT.put_line('l_all_users_cursor_row.created=' || l_all_users_cursor_row.created); END; / l_username=SYS l_all_users_row.username=SYS l_all_users_row.user_id=0 l_all_users_row.created=18-MAR-2004 08:02:17 l_all_users_cursor_row.username=SYS l_all_users_cursor_row.created=18-MAR-2004 08:02:17 PL/SQL procedure successfully completed. SQL>
%TYPE qualifier signifies that the variable datatype should match that of the specified table column, while the
%ROWTYPE qualifier signifies that the variable datatype should be a record structure that matches the specified table or cursor structure. Notice that the record structures use the dot notation (variable.column) to reference the individual column data within the record structure.
Values can be assigned to variables directly using the ":=" assignment operator, via a
SELECT ... INTO statement or when used as
IN OUT parameter from a procedure. All three assignment methods are shown in the example below.
DECLARE l_number NUMBER; PROCEDURE add(p1 IN NUMBER, p2 IN NUMBER, p3 OUT NUMBER) AS BEGIN p3 := p1 + p2; END; BEGIN -- Direct assignment. l_number := 1; -- Assignment via a select. SELECT 1 INTO l_number FROM dual; -- Assignment via a procedure parameter. add(1, 2, l_number); END; /
Using SQL in PL/SQL
The SQL language is fully integrated into PL/SQL, so much so that they are often mistaken as being a single language by newcomers. It is possible to manuallly code the retrieval of data using explicit cursors, or let Oracle do the hard work and use implicit cursors. Examples of both explicit implicit cursors are presented below, all of which rely on the following table definition table.
CREATE TABLE sql_test ( id NUMBER(10), description VARCHAR2(10) ); INSERT INTO sql_test (id, description) VALUES (1, 'One'); INSERT INTO sql_test (id, description) VALUES (2, 'Two'); INSERT INTO sql_test (id, description) VALUES (3, 'Three'); COMMIT;
SELECT ... INTO statement allows data from one or more columns of a specific row to be retrieved into variables or record structures using an implicit cursor.
SET SERVEROUTPUT ON DECLARE l_description VARCHAR2(10); BEGIN SELECT description INTO l_description FROM sql_test WHERE id = 1; DBMS_OUTPUT.put_line('l_description=' || l_description); END; / l_description=One PL/SQL procedure successfully completed. SQL>
The previous example can be recoded to use an explicit cursor a shown below. Notice that the cursor is now defined in the declaration section and is explicitly opened and closed, making the code larger and a little ugly.
SET SERVEROUTPUT ON DECLARE l_description VARCHAR2(10); CURSOR c_data (p_id IN NUMBER) IS SELECT description FROM sql_test WHERE id = p_id; BEGIN OPEN c_data (p_id => 1); FETCH c_data INTO l_description; CLOSE c_data; DBMS_OUTPUT.put_line('l_description=' || l_description); END; / l_description=One PL/SQL procedure successfully completed. SQL>
When a query returns multiple rows is can be processed within a loop. The following example uses a cursor FOR-LOOP to cycle through multiple rows of an implicit cursor. Notice there is no need for a variable definition as "cur_rec" acts as a pointer to the current record of the cursor.
SET SERVEROUTPUT ON BEGIN FOR cur_rec IN (SELECT description FROM sql_test) LOOP DBMS_OUTPUT.put_line('cur_rec.description=' || cur_rec.description); END LOOP; END; / cur_rec.description=One cur_rec.description=Two cur_rec.description=Three PL/SQL procedure successfully completed. SQL>
The explicit cursor version of the previous example is displayed below. Once again the cursor management is all done manually, but this time the exit from the loop must be managed manually also.
SET SERVEROUTPUT ON DECLARE l_description VARCHAR2(10); CURSOR c_data IS SELECT description FROM sql_test; BEGIN OPEN c_data; LOOP FETCH c_data INTO l_description; EXIT WHEN c_data%NOTFOUND; DBMS_OUTPUT.put_line('l_description=' || l_description); END LOOP; CLOSE c_data; END; / l_description=One l_description=Two l_description=Three PL/SQL procedure successfully completed. SQL>
In most situations the implicit cursors provide a faster and cleaner solution to data retrieval than their explicit equivalents.
Branching and Conditional Control
CASE statements allow code to decide on the correct course of action for the current circumstances. In the following example the
IF-THEN-ELSE statement is used to decide if today is a weekend day.
SET SERVEROUTPUT ON DECLARE l_day VARCHAR2(10); BEGIN l_day := TRIM(TO_CHAR(SYSDATE, 'DAY')); IF l_day IN ('SATURDAY', 'SUNDAY') THEN DBMS_OUTPUT.put_line('It''s the weekend!'); ELSE DBMS_OUTPUT.put_line('It''s not the weekend yet!'); END IF; END; /
First, the expression between the IF and the THEN is evaluated. If that expression equates to TRUE the code between the THEN and the ELSE is performed. If the expression equates to FALSE the code between the ELSE and the END IF is performed. The IF-THEN-ELSE statement can be extended to cope with multiple decisions by using the ELSIF keyword. The example below uses this extended form to produce a different message for Saturday and Sunday.
SET SERVEROUTPUT ON DECLARE l_day VARCHAR2(10); BEGIN l_day := TRIM(TO_CHAR(SYSDATE, 'DAY')); IF l_day = 'SATURDAY' THEN DBMS_OUTPUT.put_line('The weekend has just started!'); ELSIF l_day = 'SUNDAY' THEN DBMS_OUTPUT.put_line('The weekend is nearly over!'); ELSE DBMS_OUTPUT.put_line('It''s not the weekend yet!'); END IF; END; /
CASE expressions were introduced in the later releases of Oracle 8i, but Oracle 9i included support for
CASE statements in PL/SQL for the first time. The
CASE statement is the natural replacement for large
IF-THEN-ELSIF-ELSE statements. The following code gives an example of a matched
SET SERVEROUTPUT ON DECLARE l_day VARCHAR2(10); BEGIN l_day := TRIM(TO_CHAR(SYSDATE, 'DAY')); CASE l_day WHEN 'SATURDAY' THEN DBMS_OUTPUT.put_line('The weekend has just started!'); WHEN 'SUNDAY' THEN DBMS_OUTPUT.put_line('The weekend is nearly over!'); ELSE DBMS_OUTPUT.put_line('It''s not the weekend yet!'); END CASE; END; /
WHEN clauses of a matched
CASE statement simply state the value to be compared. If the value of the variable specified after the
CASE keyword matches this comparison value the code after the
THEN keyword is performed.
CASE statement has a slightly different format, with each WHEN clause containing a full expression, as shown below.
SET SERVEROUTPUT ON DECLARE l_day VARCHAR2(10); BEGIN l_day := TRIM(TO_CHAR(SYSDATE, 'DAY')); CASE WHEN l_day = 'SATURDAY' THEN DBMS_OUTPUT.put_line('The weekend has just started!'); WHEN l_day = 'SUNDAY' THEN DBMS_OUTPUT.put_line('The weekend is nearly over!'); ELSE DBMS_OUTPUT.put_line('It''s not the weekend yet!'); END CASE; END; /
Loops allow sections of code to be processed multiple times. In its most basic form a loop consists of the
END LOOP statement, but this form is of little use as the loop will run forever.
BEGIN LOOP NULL; END LOOP; END; /
Typically you would expect to define an end condition for the loop using the
EXIT WHEN statement along with a Boolean expression. When the expression equates to true the loop stops. The example below uses this syntax to pint out numbers from 1 to 5.
SET SERVEROUTPUT ON DECLARE i NUMBER := 1; BEGIN LOOP EXIT WHEN i > 5; DBMS_OUTPUT.put_line(i); i := i + 1; END LOOP; END; /
The placement of the
EXIT WHEN statement can affect the processing inside the loop. For example, placing it at the start of the loop means the code within the loop may be executed "0 to many" times, like a while-do loop in other language. Placing the
EXIT WHEN at the end of the loop means the code within the loop may be executed "1 to many" times, like a do-while loop in other languages.
FOR-LOOP statement allows code within the loop to be repeated a specified number of times based on the lower and upper bounds specified in the statement. The example below shows how the previous example could be recorded to use a
SET SERVEROUTPUT ON BEGIN FOR i IN 1 .. 5 LOOP DBMS_OUTPUT.put_line(i); END LOOP; END; /
WHILE-LOOP statement allows code within the loop to be repeated until a specified expression equates to TRUE. The following example shows how the previous examples can be re-coded to use a
SET SERVEROUTPUT ON DECLARE i NUMBER := 1; BEGIN WHILE i <= 5 LOOP DBMS_OUTPUT.put_line(i); i := i + 1; END LOOP; END; /
In addition to these loops a special cursor
FOR-LOOP is available as seen previously.
GOTO statement allows a program to branch unconditionally to a predefined label. The following example uses the
GOTO statement to repeat the functionality of the examples in the previous section.
SET SERVEROUTPUT ON DECLARE i NUMBER := 1; BEGIN LOOP IF i > 5 THEN GOTO exit_from_loop; END IF; DBMS_OUTPUT.put_line(i); i := i + 1; END LOOP; << exit_from_loop >> NULL; END; /
In this example the GOTO has been made conditional by surrounding it with an
IF statement. When the
GOTO is called the program execution immediately jumps to the appropriate label, defined using double-angled brackets.
Procedures, Functions and Packages
Procedures and functions allow code to be named and stored in the database, making code reuse simpler and more efficient. Procedures and functions still retain the block format, but the DECLARE keyword is replaced by PROCEDURE or FUNCTION definitions, which are similar except for the additional return type definition for a function. The following procedure displays numbers between upper and lower bounds defined by two parameters, then shows the output when it's run.
CREATE OR REPLACE PROCEDURE display_numbers ( p_lower IN NUMBER, p_upper IN NUMBER) AS BEGIN FOR i IN p_lower .. p_upper LOOP DBMS_OUTPUT.put_line(i); END LOOP; END; / SET SERVEROUTPUT ON EXECUTE display_numbers(2, 6); 2 3 4 5 6 PL/SQL procedure successfully completed. SQL>
The following function returns the difference between upper and lower bounds defined by two parameters.
CREATE OR REPLACE FUNCTION difference ( p_lower IN NUMBER, p_upper IN NUMBER) RETURN NUMBER AS BEGIN RETURN p_upper - p_lower; END; / VARIABLE l_result NUMBER BEGIN :l_result := difference(2, 6); END; / PL/SQL procedure successfully completed. PRINT l_result L_RESULT ---------- 4 SQL>
Packages allow related code, along with supporting types, variables and cursors, to be grouped together. The package is made up of a specification that defines the external interface of the package, and a body that contains all the implementation code. The following code shows how the previous procedure and function could be grouped into a package.
CREATE OR REPLACE PACKAGE my_package AS PROCEDURE display_numbers ( p_lower IN NUMBER, p_upper IN NUMBER); FUNCTION difference ( p_lower IN NUMBER, p_upper IN NUMBER) RETURN NUMBER; END; / CREATE OR REPLACE PACKAGE BODY my_package AS PROCEDURE display_numbers ( p_lower IN NUMBER, p_upper IN NUMBER) AS BEGIN FOR i IN p_lower .. p_upper LOOP DBMS_OUTPUT.put_line(i); END LOOP; END; FUNCTION difference ( p_lower IN NUMBER, p_upper IN NUMBER) RETURN NUMBER AS BEGIN RETURN p_upper - p_lower; END; END; /
Once the package specification and body are compiled they can be executed as before, provided the procedure and function names are prefixed with the package name.
SET SERVEROUTPUT ON EXECUTE my_package.display_numbers(2, 6); 2 3 4 5 6 PL/SQL procedure successfully completed. VARIABLE l_result NUMBER BEGIN :l_result := my_package.difference(2, 6); END; / PL/SQL procedure successfully completed. PRINT l_result L_RESULT ---------- 4 SQL>
Since the package specification defines the interface to the package, the implementation within the package body can be modified without invalidating any dependent code, thus breaking complex dependency chains. A call to any element in the package causes the whole package to be loaded into memory, improving performance compared to loading several individual procedures and functions.
Record types are composite data structures, or groups of data elements, each with its own definition. Records can be used to mimic the row structures of tables and cursors, or as a convenient was to pass data between subprograms without listing large number of parameters.
When a record type must match a particular table or cursor structure it can be defined using the
%ROWTYPE attribute, removing the need to define each column within the record manually. Alternatively, the record can be specified manually. The following code provides an example of how records can be declared and used in PL/SQL.
SET SERVEROUTPUT ON DECLARE -- Define a record type manually. TYPE t_all_users_record IS RECORD ( username VARCHAR2(30), user_id NUMBER, created DATE ); -- Declare record variables using the manual and %ROWTYPE methods. l_all_users_record_1 t_all_users_record; l_all_users_record_2 all_users%ROWTYPE; BEGIN -- Return some data into once record structure. SELECT * INTO l_all_users_record_1 FROM all_users WHERE username = 'SYS'; -- Display the contents of the first record. DBMS_OUTPUT.put_line('l_all_users_record_1.username=' || l_all_users_record_1.username); DBMS_OUTPUT.put_line('l_all_users_record_1.user_id=' || l_all_users_record_1.user_id); DBMS_OUTPUT.put_line('l_all_users_record_1.created=' || l_all_users_record_1.created); -- Assign the values to the second record structure in a single operation. l_all_users_record_2 := l_all_users_record_1; -- Display the contents of the second record. DBMS_OUTPUT.put_line('l_all_users_record_2.username=' || l_all_users_record_2.username); DBMS_OUTPUT.put_line('l_all_users_record_2.user_id=' || l_all_users_record_2.user_id); DBMS_OUTPUT.put_line('l_all_users_record_2.created=' || l_all_users_record_2.created); l_all_users_record_1 := NULL; -- Display the contents of the first record after deletion. DBMS_OUTPUT.put_line('l_all_users_record_1.username=' || l_all_users_record_1.username); DBMS_OUTPUT.put_line('l_all_users_record_1.user_id=' || l_all_users_record_1.user_id); DBMS_OUTPUT.put_line('l_all_users_record_1.created=' || l_all_users_record_1.created); END; / l_all_users_record_1.username=SYS l_all_users_record_1.user_id=0 l_all_users_record_1.created=18-MAR-2004 08:02:17 l_all_users_record_2.username=SYS l_all_users_record_2.user_id=0 l_all_users_record_2.created=18-MAR-2004 08:02:17 l_all_users_record_1.username= l_all_users_record_1.user_id= l_all_users_record_1.created= PL/SQL procedure successfully completed. SQL>
Notice how the records can be assigned to each other directly, and how all elements within a record can be initialized with a single assignment of a NULL value.
Oracle implements Objects through the use of
TYPE declarations, defined in a similar way to packages. Unlike packages where the instance of the package is limited to the current session, an instance of an object type can be stored in the database for later use. The definition of the type contains a comma separated list of attributes/properties, defined in the same way as package variables, and member functions/procedures. If a type contains member functions/procedures, the procedural work for these elements is defined in the
To see how objects can be used let's assume we want to create one to represent a person. In this case, a person is defined by three attributes (first_name, last_name, date_of_birth). We would also like to be able to return the age of the person, so this is included as a member function (get_age).
CREATE OR REPLACE TYPE t_person AS OBJECT ( first_name VARCHAR2(30), last_name VARCHAR2(30), date_of_birth DATE, MEMBER FUNCTION get_age RETURN NUMBER ); / Type created. SQL>
Next the type body is created to implement the get_age member function.
CREATE OR REPLACE TYPE BODY t_person AS MEMBER FUNCTION get_age RETURN NUMBER AS BEGIN RETURN TRUNC(MONTHS_BETWEEN(SYSDATE, date_of_birth)/12); END get_age; END; / Type body created. SQL>
Once the object is defined it can be used to define a column in a database table.
CREATE TABLE people ( id NUMBER(10) NOT NULL, person t_person ); Table created. SQL>
To insert data into the PEOPLE table we must use the t_person() constructor. This can be done as part of a regular DML statement, or using PL/SQL.
INSERT INTO people (id, person) VALUES (1, t_person('John', 'Doe', TO_DATE('01/01/2000','DD/MM/YYYY'))); 1 row created. COMMIT; Commit complete. DECLARE l_person t_person; BEGIN l_person := t_person('Jane','Doe', TO_DATE('01/01/2001','DD/MM/YYYY')); INSERT INTO people (id, person) VALUES (2, l_person); COMMIT; END; / PL/SQL procedure successfully completed. SQL>
Once the data is loaded it can be queried using the dot notation.
The query below shows this in action.
SELECT p.id, p.person.first_name, p.person.get_age() AS age FROM people p; ID PERSON.FIRST_NAME AGE ---------- ------------------------------ ---------- 1 John 5 2 Jane 4 2 rows selected. SQL>
Oracle uses collections in PL/SQL the same way other languages use arrays. You can read more about the types of collections available here.
TriggersDatabase triggers are stored programs associated with a specific table, view or system events, such that when the specific event occurs the associated code is executed. Triggers can be used to validate data entry, log specific events, perform maintenance tasks or perform additional application logic. The following example shows how a table trigger could be used to keep an audit of update actions.
-- Create and populate an items table and creat an audit log table. CREATE TABLE items ( id NUMBER(10), description VARCHAR2(50), price NUMBER(10,2), CONSTRAINT items_pk PRIMARY KEY (id) ); CREATE SEQUENCE items_seq; INSERT INTO items (id, description, price) VALUES (items_seq.NEXTVAL, 'PC', 399.99); CREATE TABLE items_audit_log ( id NUMBER(10), item_id NUMBER(10), description VARCHAR2(50), old_price NUMBER(10,2), new_price NUMBER(10,2), log_date DATE, CONSTRAINT items_audit_log_pk PRIMARY KEY (id) ); CREATE SEQUENCE items_audit_log_seq; -- Create a trigger to log price changes of items. CREATE OR REPLACE TRIGGER items_aru_trg AFTER UPDATE OF price ON items FOR EACH ROW BEGIN INSERT INTO items_audit_log (id, item_id, description, old_price, new_price, log_date) VALUES (items_audit_log_seq.NEXTVAL, :new.id, :new.description, :old.price, :new.price, SYSDATE); END; / -- Check the current data in the audit table, should be no rows. COLUMN description FORMAT A10 SELECT * FROM items_audit_log; no rows selected -- Update the price of an item. UPDATE items SET price = 499.99 WHERE id = 1; -- Check the audit table again. COLUMN description FORMAT A10 SELECT * FROM items_audit_log; ID ITEM_ID DESCRIPTIO OLD_PRICE NEW_PRICE LOG_DATE ---------- ---------- ---------- ---------- ---------- -------------------- 1 1 PC 399.99 499.99 19-AUG-2005 10:14:11 1 row selected. -- Clean up. DROP TABLE items_audit_log; DROP TABLE items;
From this you can see that the trigger fired when the price of the record was updated, allowing us to audit the action.
The following trigger sets the current_schema parameter for each session logging on as the APP_LOGON user, making the default schema that of the SCHEMA_OWNER user.
CREATE OR REPLACE TRIGGER APP_LOGON.after_logon_trg AFTER LOGON ON APP_LOGON.SCHEMA BEGIN EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER'; END; /
You can read more about database triggers here.
When PL/SQL detects an error normal execution stops and an exception is raised, which can be captured and processed within the block by the exception handler if it is present. If the block does not contain an exception handler section the exception propagates outward to each successive block until a suitable exception handler is found, or the exception is presented to the client application.
Oracle provides many predefined exceptions for common error conditions, like
NO_DATA_FOUND when a
SELECT ... INTO statement returns no rows. The following example shows how exceptions are trapped using the appropriate exception handler. Assume we want to return the username associated with a specific user_id value, we might do the following.
SET SERVEROUTPUT ON DECLARE l_user_id all_users.username%TYPE := 0; l_username all_users.username%TYPE; BEGIN SELECT username INTO l_username FROM all_users WHERE user_id = l_user_id; DBMS_OUTPUT.put_line('l_username=' || l_username); END; / l_username=SYS PL/SQL procedure successfully completed. SQL>
That works fine for user_id values that exist, but look what happens if we use one that doesn't.
SET SERVEROUTPUT ON DECLARE l_user_id all_users.username%TYPE := 999999; l_username all_users.username%TYPE; BEGIN SELECT username INTO l_username FROM all_users WHERE user_id = l_user_id; DBMS_OUTPUT.put_line('l_username=' || l_username); END; / DECLARE * ERROR at line 1: ORA-01403: no data found ORA-06512: at line 5 SQL>
This is not a very user friendly message, so we can trap this error and produce something more meaningful to the users.
SET SERVEROUTPUT ON DECLARE l_user_id all_users.username%TYPE := 999999; l_username all_users.username%TYPE; BEGIN SELECT username INTO l_username FROM all_users WHERE user_id = l_user_id; DBMS_OUTPUT.put_line('l_username=' || l_username); EXCEPTION WHEN NO_DATA_FOUND THEN DBMS_OUTPUT.put_line('No users have a user_id=' || l_user_id); END; / No users have a user_id=999999 PL/SQL procedure successfully completed. SQL>
It is possible to declare your own exceptions for application specific errors, or associate them with Oracle "ORA-" messages, which are executed using the RAISE statement. The example below builds on the previous example using a user defined exception to signal an application specific error.
SET SERVEROUTPUT ON DECLARE l_user_id all_users.username%TYPE := 0; l_username all_users.username%TYPE; ex_forbidden_users EXCEPTION; BEGIN SELECT username INTO l_username FROM all_users WHERE user_id = l_user_id; -- Signal an error is the SYS or SYSTEM users are queried. IF l_username IN ('SYS', 'SYSTEM') THEN RAISE ex_forbidden_users; END IF; DBMS_OUTPUT.put_line('l_username=' || l_username); EXCEPTION WHEN NO_DATA_FOUND THEN DBMS_OUTPUT.put_line('No users have a user_id=' || l_user_id); WHEN ex_forbidden_users THEN DBMS_OUTPUT.put_line('Don''t mess with the ' || l_username || ' user, it is forbidden!'); END; / Don't mess with the SYS user, it is forbidden! PL/SQL procedure successfully completed. SQL>
The code still handles users that don't exist, but now it also raises an exception if the user returned is either SYS or SYSTEM.
My Utopian Development Environment
I wrote a blog post about this many years ago. You can read it here. I think it's worth just spending a little time reiterating some of the main points here. It may not be to everyone's liking, but I've always found it to be the most secure and flexible approach I've come across.
I believe the use of PL/SQL Application Program Interfaces (APIs) should be compulsory. Ideally, client application developers should have no access to tables, but instead access data via PL/SQL APIs, or possibly views if absolutely necessary.
This has a number of beneficial effects, including:
- Security and auditing mechanisms can be implemented and maintained at the database level, with little or no impact on the client application layer.
- It removes the need for triggers as all inserts, updates and deletes are wrapped in APIs. Instead of writing triggers you simply add the code into the API.
- It prevents people who don't understand SQL writing inefficient queries. All SQL should be written by PL/SQL developers or DBAs, reducing the likelihood of bad queries.
- The underlying structure of the database is hidden from the client application developers, so it hides complexity and structural changes can be made without client applications being changed.
- The API implementation can be altered and tuned without affecting the client application layer. Reducing the need for redeployments of applications.
- The same APIs are available to all applications that access the database. Resulting in reduced duplication of effort.
This sounds a little extreme, but this approach has paid dividends for me again and again. Let's elaborate on these points to explain why this approach is so successful.
It's a sad fact that auditing and security are often only brought into focus after something bad has happened. Having the ability to revise and refine these features is a massive bonus. If this means you have to re-factor your whole application you are going to have problems. If on the other hand it can be revised in your API layer you are on to a winner.
Over-reliance on database triggers is a bad thing in my opinion. It seems every company I've worked for has at one time or another used triggers to patch a “hole” or implement some business functionality in their application. Every time I see this my heart sinks. Invariably these triggers get disabled by accident and bits of functionality go AWOL, or people forget they exist and recode some of their functionality elsewhere in the application. It's far easier to wrap the transactional processing in an API that includes all necessary functionality, thereby removing the need for table triggers entirely.
Many client application developers have to be able to work with several database engines, and as a result are not always highly proficient at coding against Oracle databases. Added to that, some development architectures such as J2EE positively discourage developers from working directly with the database. You wouldn't ask an inexperienced person to fix your car, so why would you ask one to write SQL for you? Abstracting the SQL in an API leaves the client application developers to do what they do best, while you PL/SQL programmers can write the most efficient SQL and PL/SQL possible.
During the lifetime of an application many changes can occur in the physical implementation of the database. It's nice to think that the design will be perfected before application development starts, but in reality this seldom seems to be the case. The use of APIs abstracts the developers from the physical implementation of the database, allowing change without impacting on the application.
In the same way, it is not possible to foresee all possible performance problems during the coding phase of an application. Many times developers will write and test code with unrealistic data, only to find the code that was working perfectly in a development environment works badly in a production environment. If the data manipulation layer is coded as an API it can be tuned without re-coding sections of the application, after all the implementation has changed, not the interface.
A problem I see time and time again is that companies invest heavily in coding their business logic into a middle tier layer on an application server, then want to perform data loads either directly into the database, or via a tool that will not link to their middle tier application. As a result they have to re-code sections of their business logic into PL/SQL or some other client language. Remember, it's not just the duplication of effort during the coding, but also the subsequent maintenance. Since every language worth using can speak to Oracle via OCI, JDBC or ODBC it makes sense to keep your logic in the database and let every application or data load use the same programming investment.
Of course, you may not always have full control of your development environment, but it's worth bearing these points in mind.
Additional functionality that may be useful to develop your API layer is listed below.
For more information see: