Enlaces relacionados:

Transcripción

1 1.INTRODUCCION PL/SQL (Procedural Language ó Programming Language, según distintas fuentes, aunque la oficial es la primera) es el lenguaje utilizado por Oracle como extensión al SQL, y que nos va a permitir introducir los elementos existentes en los demás lenguajes de programación y dirigir el flujo de un programa mediante bloques de código. El elemento principal del PL/SQL es el bloque, que como acabamos de decir contendrá sentencias condicionales, bucles, llamadas a procedimientos y/o funciones, etc... Enlaces relacionados: 2.BLOQUES Veremos que hay dos tipos de bloques (anónimos y nombrados) y que estos se utilizan en todas las construcciones PL/SQL: Bloques anónimos, Disparadores de aplicación (para Forms, Reports, Graphics, y las herramientas de desarrollo nativas de Oracle), Disparadores de Base de datos, Procedimientos o funciones almacenada en la Base de datos, Procedimientos o funciones de aplicación (para Forms, Reports, Graphics, y las herramientas de desarrollo nativas de Oracle) y Paquetes de Base de datos (dejaremos aparte los tipos de objetos, ya que no los abordaremos en este curso, sólo recordar que Oracle 8 es una base de datos orientada a objetos y estos forman parte de la BD). Cada estructura PL/SQL contiene uno o más bloques. Los bloques pueden estar separados uno tras otro o anidados unos dentro de otros BLOQUES ANONIMOS Los bloques anónimos son, como su nombre indica, bloques sin nombre. Se ejecutan normalmente como scripts independientes o dentro de una aplicación. La estructura es la siguiente: DECLARE (opcional) Definición de variables, tipos y objetos a utilizar en el bloque. Sentencias ejecutables (opcional) Acciones a realizar si ocurre algún error en las sentencias ejecutables. END ; Los elementos y END son obligatorios e incluyen las sentencias a ejecutar. La sección DECLARE es opcional y nos servirá para declarar las variables, constantes, cursores y excepciones definidas por el usuario que vamos a usar dentro del bloque. La sección es también opcional y es la encargada de atrapar los errores, en caso de que se produzcan y realizar las acciones oportunas según el tipo de excepción. Esta sección debe preceder inmediatamente a END. Como podéis observar el punto y coma va solamente en el END ya que se considera al bloque como un todo, pero Pág 1 de 9

2 dentro de la sección, las instrucciones deben ir siempre terminadas por el punto y coma. Como siempre, vamos a ver un ejemplo para aclarar las cosas: DECLARE WHERE codigo=1 ; Veamos: en la sección DECLARE establecemos la variable v_nombre del mismo tipo y longitud que el campo nombre de la tabla EMPLEADOS para recoger ese dato en el programa. Después del ejecutamos una sentencia SELECT con la particularidad de la clausula INTO que provoca que el campo nombre se guarde en la variable v_nombre. En este caso buscamos el nombre del empleado cuyo código es el 1. Finalmente, terminamos el bloque con Vale, todo correcto, pero supongamos que la sentencia SELECT no recupera ningún registro porque no hay registros grabados, o porque no existe el empleado 1, o simplemente porque se produce un error de sistema. Para eso está la sección : DECLARE WHERE codigo=1 ; Si no se encuentra ningún registro que cumpla las condiciones de la sentencia SELECT, se lanza una excepción NO_DATA_FOUND y la sección la capturará, almacenando en la variable v_error el mensaje apropiado. Otra cosa será lo que hagamos con ello después. Si se produce cualquier otra excepción, se capturará por WHEN OTHERS que recoge cualquier excepción que no se haya especificado antes, por lo que es muy conveniente ponerla siempre. La gestión de excepciones la iremos viendo a medida que avancemos ya que es bastante ilustrativo hacerlo así. Considero que dedicar un capítulo a las excepciones puede llegar a ser inútil si las vamos explicando paso a paso. Importante indicar que una SELECT dentro de un bloque PL/SQL solo puede devolver un registro. En este caso no nos hemos preocupado del asunto pues el campo codigo es clave primaria de la tabla EMPLEADOS. Pág 2 de 9

3 2.2.- BLOQUES NOMBRADOS (SUBPROGRAMAS) Los subprogramas son bloques nombrados que pueden tener parámetros y ser llamados por otros bloques. PL/SQL dispone de dos tipos: procedimientos y funciones. Ambos pueden residir en la aplicación o en la propia base de datos. Su estructura es la siguiente: Cabecera IS Definición de variables, tipos y objetos a utilizar en el bloque. Sentencias ejecutables (opcional) Acciones a realizar si ocurre algún error en las sentencias ejecutables. END ; Como podéis la diferencia con los bloques anónimos está en la sección de declaraciones. Aquí no se usa DECLARE y sin embargo tenemos una Cabecera que consta de: Si se trata de un procedimiento: PROCEDURE nombre_procedimiento(parametros) Si se trata de una función: FUNCTION nombre_funcion(parametros) RETURN tipo Los parámetros son opcionales y pueden ser de entrada, de salida o de entrada y salida al mismo tiempo. En el caso de las funciones, el tipo devuelto especifica el tipo de dato que devuelve la función mediante la sentencia RETURN expresión. Que se especifica en la sección ejecutable y en la de. Es muy importante recordar que una función SIEMPRE debe devolver un valor, por lo que hay que tener especial atención a los errores que se puedan generar, capturarlos y devolver un valor incluso en caso de error. Como siempre, unos ejemplos: PROCEDIMIENTO: PROCEDURE nombre_empleado(p_codigo IN NUMBER) IS WHERE codigo=p_codigo ; Pág 3 de 9

4 Vemos la sección de cabecera con el nombre del procedimiento y el parámetro pasado (IN = de entrada). Claro, ahora más de uno dirá: y para qué sirve este procedimiento si el nombre del empleado que recuperamos, se queda en la variable v_nombre. Cierto, pero tranquilos, vamos a ver los parámetros de salida y resolvemos el problema. De nuevo escribimos nuestro procedimiento: PROCEDURE nombre_empleado(p_codigo IN NUMBER, P_NOMBRE OUT VARCHAR2) IS P_NOMBRE := NULL; SELECT nombre INTO P_NOMBRE WHERE codigo=p_codigo ; Ahora en el parámetro P_NOMBRE saldrá (OUT) el nombre del empleado que hemos recuperado. Como se puede ver, he eliminado la variable v_nombre de la sección de declaraciones ya que ahora no nos hace falta, y en la SELECT INTO metemos el valor directamente en el parámetro de salida P_NOMBRE. También vemos que justo antes de la SELECT asignamos el valor NULL al parámetro. Esto no es obligatorio, pero es buena costumbre ya que así, en caso de error, el parámetro P_NOMBRE contendrá un valor: el valor NULL. FUNCION: El mismo ejemplo pero con una función: FUNCTION nombre_empleado(p_codigo IN NUMBER) RETURN VARCHAR2 IS WHERE codigo=p_codigo ; RETURN v_nombre; RETURN v_error ; RETURN v_error ; Por supuesto, una función puede devolver más de un valor haciendo uso de los parámetros de salida (OUT). Pág 4 de 9

5 Observar que aunque se produzca un error hacemos que la función devuelva un valor. Esto lo hacemos así ya que cuando se produce una excepción dentro de un bloque, se ejecuta el código del manejador de la excepción y se finaliza la ejecución del código del bloque en cuestión. Es decir, en el caso anterior, si se produce un error, la función devolverá el valor de v_error y no el de v_nombre ya la sentencia RETURN v_nombre no se llega a ejecutar. Hemos dicho que los bloques nombrados, ya sean procedimientos o funciones pueden estar almacenados en la aplicación o en la base de datos. Durante el curso nos ceñiremos al caso de almacenarlos en la base de datos ya que escapa a este documento el entrar a explicar las herramientas de desarrollo nativas de Oracle (Developer, Discover, etc...). En este sentido, podemos utilizar para almacenar los procedimientos o funciones en la base de datos, las aplicaciones suministradas por Oracle (Procedure Builder) o utilizar aplicaciones de terceros (SQL Navigator, Toad, etc..), pero insisto, vamos a suponer que solo tenemos un editor de textos y la herramienta SQL*Plus para poder ejecutar sentencias o scripts SQL. Dicho esto, ahora os preguntareis: como almaceno la función anterior en la base de datos entonces?. Vamos a verlo: CREATE OR REPLACE FUNCTION nombre_empleado(p_codigo IN NUMBER) RETURN VARCHAR2 IS WHERE codigo=p_codigo ; RETURN v_nombre; RETURN v_error ; RETURN v_error ; / Así de sencillo. Ponemos delante CREATE OR REPLACE para crearla o sustituirla en caso de que ya exista y de esta forma queda almacenada en la base de datos. Fácil no?. Con un procedimiento lo haríamos igual. La clausula OR REPLACE es opcional como habréis deducido ya. El lector atento se habrá dado cuenta de la barra / al final. Sí, no se trata de un error. Es para que SQL*Plus ejecute el código directamente. No voy a tratar el SQL*Plus ya que tampoco es necesario para aprender PL/SQL, aunque es la herramienta básica, al final la mayoría usamos otras herramientas más avanzadas (SQL*Plus es una consola de SQL y poco más). Y cómo borro lo que acabo de almacenar en la base de datos?. La sentencia para borrar un procedimiento almacenado en la base de datos es: Pág 5 de 9

6 DROP PROCEDURE nombre_procedimiento ; Y,de forma análoga, para borrar una función almacenada: DROP FUNCTION nombre_funcion ; Es importante recordar que no hay posibilidad de ROLLBACK después de una sentencia DDL, por lo que una instrucción DROP es definitiva (aviso para los gatillos rápidos ). Volveremos a los procedimientos y funciones más adelante BLOQUES ANIDADOS Ya hemos comentado que los bloques se pueden anidar, ya sea con los bloques anónimos como con los nombrados. El concepto es muy sencillo y, básicamente, consiste en encerrar entre END los bloques de código susceptibles de provocar algún error para así poder capturarlo y proceder en consecuencia. Por ejemplo: supongamos que tenemos un procedimiento que inserta un registro en la tabla DEPARTAMENTOS y actualiza en EMPLEADOS el departamento de un empleado con el nuevo creado. Pero sólo debe realizarse la transacción si se tiene éxito en los dos casos. Por supuesto, si no se puede realizar la inserción del departamento, es absurdo intentar actualizar el departamento del empleado ya que no existirá (falló la inserción) PROCEDURE INSERTA_DEP_EMP(p_departamento IN NUMBER, p_nom_departamento IN VARCHAR2, p_cod_empleado IN NUMBER p_resultado OUT VARCHAR2) IS -- Primer bloque. Anidado dentro del bloque principal INSERT INTO DEPARTAMENTOS VALUES(p_departamento, p_nom_departamento); -- Segundo bloque. Anidado dentro del bloque del INSERT -- Se ejecutará si no se produjo error en el anterior. UPDATE EMPLEADOS SET departamento=p_departamento WHERE codigo=p_cod_empleado ; -- AQUI LLEGAMOS SI NO SE PRODUJO NINGUNA EXCEPCION -- GRABAMOS LA TRANSACCION. COMMIT; ROLLBACK ; p_resultado := 'Error al actualizar el empleado'; p_resultado := 'Error al insertar Departamento'; Pág 6 de 9

7 Esta es una forma de hacerlo, sobre todo para poder observar perfectamente el anidamiento de los bloques y el control de las excepciones (errores). Daros cuenta que insertamos el registro y si todo ha ido bien, actualizamos el registro del empleado con el nuevo departamento. Si también ha tenido éxito el update, hacemos el commit, grabando así la transacción. Si falla el insert, devolvemos en la variable p_resultado la causa del error y no hemos hecho nada. Si lo que falla es el update posterior, deshacemos la inserción (ROLLBACK) y devolvemos la causa del error. También podríamos haber colocado un SAVEPOINT al principio para hacer el ROLLBACK TO SAVEPOINT en lugar del ROLLBACK, asegurándonos así que solo deshacemos el insert y no alguna transacción pendiente que pudiera haber. El código final sería: PROCEDURE INSERTA_DEP_EMP(p_departamento IN NUMBER, p_nom_departamento IN VARCHAR2, p_cod_empleado IN NUMBER p_resultado OUT VARCHAR2) IS -- Primer bloque. Anidado dentro del bloque principal SAVEPOINT trans1 INSERT INTO DEPARTAMENTOS VALUES(p_departamento, p_nom_departamento); -- Segundo bloque. Anidado dentro del bloque del INSERT -- Se ejecutará si no se produjo error en el anterior. UPDATE EMPLEADOS SET departamento=p_departamento WHERE codigo=p_cod_empleado ; -- AQUI LLEGAMOS SI NO SE PRODUJO NINGUNA EXCEPCION -- GRABAMOS LA TRANSACCION. COMMIT; ROLLBACK TO SAVEPOINT trans1; p_resultado := 'Error al actualizar el empleado'; p_resultado := 'Error al insertar Departamento'; El tema de los bloques anidados es muy útil. Otra aplicación interesante es la de buscar un valor en una tabla y si no existe, proceder a ejecutar una serie de instrucciones. Por ejemplo: en el caso anterior, si el departamento que vamos a insertar NO existe, lo insertamos, si ya existe solo actualizaremos el departamento al empleado. Veamos el código comentado: Pág 7 de 9

8 PROCEDURE INSERTA_DEP_EMP(p_departamento IN NUMBER, p_nom_departamento IN VARCHAR2, p_cod_empleado IN NUMBER p_resultado OUT VARCHAR2) IS SAVEPOINT trans1 -- Primer bloque. Anidado dentro del bloque principal -- BUSCAMOS EL DEPARTAMENTO SELECT codigo FROM DEPARTAMENTOS WHERE codigo=p_departamento ; -- No existe, así que lo insertamos (LO INTENTAMOS) -- OTRO BLOQUE ANIDADO. INSERT INTO DEPARTAMENTOS VALUES(p_departamento, p_nom_departamento); p_resultado := 'Error al insertar Departamento'; -- Segundo bloque. Anidado dentro del bloque principal -- Tanto si ya existía el departamento, como si se ha -- insertado nuevo, actualizamos el empleado. UPDATE EMPLEADOS SET departamento=p_departamento WHERE codigo=p_cod_empleado ; -- AQUI LLEGAMOS SI NO SE PRODUJO NINGUNA EXCEPCION -- GRABAMOS LA TRANSACCION. COMMIT; ROLLBACK TO SAVEPOINT trans1; p_resultado := 'Error al actualizar el empleado'; En este código falta algo, pero volveremos a él cuando veamos las excepciones definidas por usuario y cómo lanzar una excepción de forma intencionada. En particular falta un RAISE <excepcion> (además una excepción especial) para forzar la interrupción de la ejecución del código. Daros cuenta que ya dijimos que cuando se produce una excepción se ejecuta el código del manejador que la gestiona y se finaliza el bloque actual. Pero fijaros en el código anterior. Si el INSERT falla, se carga el texto en la variable p_resultado y se finaliza la ejecución del bloque, pero nada impide que se ejecute el código del siguiente bloque (el azul). De momento lo controlaremos con una variable lógica que nos indique si tenemos que realizar la actualización. De este modo además, vemos la sentencia IF THEN END IF; de control de flujo como adelanto. Ahí va el código correspondiente: Pág 8 de 9

9 PROCEDURE INSERTA_DEP_EMP(p_departamento IN NUMBER, p_nom_departamento IN VARCHAR2, p_cod_empleado IN NUMBER p_resultado OUT VARCHAR2) IS updateamos BOOLEAN; updateamos := TRUE ; SAVEPOINT trans1 -- Primer bloque. Anidado dentro del bloque principal -- BUSCAMOS EL DEPARTAMENTO SELECT codigo FROM DEPARTAMENTOS WHERE codigo=p_departamento ; -- No existe, así que lo insertamos (LO INTENTAMOS) -- OTRO BLOQUE ANIDADO. INSERT INTO DEPARTAMENTOS VALUES(p_departamento, p_nom_departamento); updateamos := FALSE ; p_resultado := 'Error al insertar Departamento'; -- Segundo bloque. Anidado dentro del bloque principal -- Tanto si ya existía el departamento, como si se ha -- insertado nuevo, actualizamos el empleado. -- Siempre y cuando no haya habido error. IF updateamos THEN UPDATE EMPLEADOS SET departamento=p_departamento WHERE codigo=p_cod_empleado ; -- AQUI LLEGAMOS SI NO SE PRODUJO NINGUNA EXCEPCION -- GRABAMOS LA TRANSACCION. COMMIT; ROLLBACK TO SAVEPOINT trans1; p_resultado := 'Error al actualizar el empleado'; END IF; Como podéis ver, el tema de bloques anidados da para mucho. Podéis empezar a imaginar las muchas posibilidades que tienen y cuando veamos las excepciones predefinidas y las definibles por usuario un poco más adelante, le sacaremos más partido aún. Pág 9 de 9