Forms6: Cerrar Report Background por código

Hace tiempo comenté aquí la forma de cerrar el Report Background Engine cada vez que se ejecuta un informe Forms6: Forzar cierre report background, en ese momento comenté que no me parecía muy optimo el cierre del Report Background Engine cada vez que se lanza un informe, pero alguna vez se me dio la necesidad de hacerlo por dos motivos:

• El usuario tenía que ejecutar dos programas en Forms con distinta configuración de NLS_LANG, uno con SPANISH_SPAIN.UTF8 y otro con SPANISH_SPAIN.WE8ISO8859P15, de forma que al ejecutar un informe se abría el Report Background con la configuración de NLS_LANG del programa que lo llamaba y el otro programa al tener abierto el Report Background no cogía bien la configuración del NLS_LANG, en ese caso lo mejor es forzar que se cierre el Report Background por cada informe.

• Conexiones remotas por Terminal Server con un programa publicado en Forms. Al lanzar un informe se abre el Report Background y queda abierto y al salir del programa se mantiene la conexión de Terminal Server por culpa del Report Background cuando en realidad ya no va a ser utilizado, en ese caso lo mejor sería forzar cerrar el Report Background al salir del programa, para ello podemos forzar que el Report Background se cierre ejecutando lo siguiente en el disparador KEY-EXIT del programa:

DECLARE

  pl_id ParamList; 

BEGIN 

  pl_id := Get_Parameter_List('CERRAR_RBE'); 

  IF NOT Id_Null(pl_id) THEN 

    Destroy_Parameter_List( pl_id ); 

  END IF; 

  pl_id := Create_Parameter_List('CERRAR_RBE'); 

  Add_Parameter(pl_id, 'PARAMFORM', TEXT_PARAMETER, 'NO');

  Add_Parameter(pl_id, 'ORACLE_SHUTDOWN', TEXT_PARAMETER, 'Yes');

  Run_Product(REPORTS, 'cerrar_rbe', SYNCHRONOUS, RUNTIME, FILESYSTEM, pl_id, NULL);

  Destroy_Parameter_List( pl_id );

END;

El informe 'cerrar_rbe' no es necesario que exista, simplemente se intenta ejecutar un informe pasándole el parámetro para forzar el cierre del Report Background.

¿Las claves foráneas producen bloqueos en Forms?

La respuesta es que si no hacemos bien las cosas es SI. Vamos a verlo mejor con un ejemplo con las típicas tablas de formación que utiliza Oracle,  DEPT y EMP:

CREATE TABLE dept (
  deptno  NUMBER(2) NOT NULL CONSTRAINT dept_pk PRIMARY KEY,
  dname   VARCHAR2(14),
  loc     VARCHAR2(13));

CREATE TABLE emp (
  empno    NUMBER(4) NOT NULL CONSTRAINT emp_pk PRIMARY KEY,
  ename    VARCHAR2(10),
  job      VARCHAR2(9),
  mgr      NUMBER(4),
  hiredate DATE,
  sal      NUMBER(7,2),
  comm     NUMBER(7,2),
  deptno   NUMBER(2) CONSTRAINT emp_ref_dept_fk
                     REFERENCES dept(deptno));

Insertamos un departamento:

INSERT INTO dept (deptno, dname, loc)
  VALUES (23, 'CONTABILIDAD', 'VIGO');

COMMIT;

Ahora insertamos un empleado:

INSERT INTO emp (empno,ename,job,mgr,
                 hiredate,
                 sal,comm,deptno)
  VALUES (1234, 'MARIOBROS', 'FONTA', 10,
          TO_DATE('16/05/1975', 'DD/MM/YYYY'),
          50000, 2000, 23);


Antes de hacer el commit, al ver los bloqueos veremos que están la tabla EMP y la DEPT bloqueadas.

SELECT lk.sid, lk.TYPE lock_type, lk.lmode,
       (SELECT o.object_name
          FROM dba_objects o
         WHERE o.object_id = lk.id1) object_name
  FROM gv$lock lk
 WHERE lk.TYPE IN ('TM', 'UL');

Lo que nos devolverá será esto:

   SID LO     LMODE OBJECT_NAME
------ -- --------- ----------------
   311 TM         3 EMP
   311 TM         3 DEPT

El bloqueo de la tabla EMP es por el registro que acabamos de insertar pero que todavía no está commitado, pero la tabla DEPT se bloquea por la clave foránea, ya que en el momento de insertar el registro en EMP existía el departamento 23 en DEPT, pero como no hemos comitado el insert en EMP tiene que bloquear el registro del departamento 23 para evitar que otra sesión borre ese registro o modifique el código del departamento.

Hasta aquí todo normal, el problema viene cuando otra sesión quiere modificar el nombre del departamento:

UPDATE dept
   SET dname = 'FINANCIERO'
 WHERE deptno = 23;

Con esta update nos dejará modificarlo sin problema, pero si en vez de hacer un update que únicamente modifica el nombre del departamento hacemos este otro (el resultado final de los datos en la tabla serán los mismos):

UPDATE dept
   SET deptno = 23,
       dname = 'FINANCIERO',
       loc = 'VIGO'
 WHERE deptno = 23;

El registro quedaría con los mismos datos, pero ya tenemos el bloqueo montado ya que le estamos diciendo que actualice el campo DEPTNO, pero la modificación de ese campo afectaría a registros introducidos por otra sesión y que todavía no están comitados, por lo que se quedará bloqueado.

Esta es la explicación del motivo, pero ¿porqué ocurre en Forms?. La respuesta la encontramos en la propiedad "Actualizar Sólo Columnas Cambiadas" a nivel de bloque, por defecto esa propiedad está a "No" con lo que para hacer un update actualizará todos los campos, incluso los que no ha modificado el usuario.

Lo recomendable para evitar bloqueos es poner esa propiedad al valor "Si".

Inyección de código

Voy a mostrar un ejemplo de como mediante inyección de código podemos consultar registros de una tabla distinta a la que tiene el bloque como origen de consulta.

Para ver el ejemplo hacemos un form asociado a la tabla DEPT (tabla típica de los ejemplos de Oracle):


SQL> DESC DEPT;
 Nombre              ¿Nulo?   Tipo
 ------------------- -------- ------------------
 DEPTNO                       NUMBER(2)
 DNAME                        VARCHAR2(14)
 LOC                          VARCHAR2(13)

Pantalla con los datos de la tabla:

Ahora vamos a ver como con ese bloque mostrar el contenido de USER_TAB_COLUMS, para ello entramos en modo de entrada consulta (pulsando F7) y en cualquiera de los campos ponemos ":" (dos puntos) y ejecutamos consulta, y tendremos la siguiente pantalla:

El objetivo de esa ventana es que el usuario pueda introducir una condición avanzada, como podría ser un AND EXISTS, un BETWEEN, ..., pero la consulta Oracle Forms la envía a la base de datos tal cual ha sido escrita por el usuario, por lo que podemos introducir lo siguiente:

1=2) UNION ALL SELECT rownum, table_name, column_name FROM user_tab_columns --

El 1=2 es para evitar los registros de la tabla DEPT, luego se añade una UNION ALL para sacar los registros de la tabla que queramos, y la consulta la terminamos con -- ya que Forms a la consulta que introduce el usuario la mete entre paréntesis, de esta forma comentamos el último parénteseis.

El resultado será el siguiente:

Este funcionamiento se puede deshabilitar, evitando que al introducir ":" en modo de entrada de consulta en un campo de forma que no se abra al ventana en donde introducir una condición adicional, para ello en Forms6 en cliente servidor se puede introducir la siguiente entrada en el regedit:

FORMS60_RESTRICT_ENTER_QUERY con el valor 1

En Forms 10g para activar o desactivarlo hay que editar el archivo al que apunta la variable envFile del archivo de configuración formsweb.cfg y modificar / añadir la variable:


FORMS_RESTRICT_ENTER_QUERY=TRUE

• TRUE: Está desactivado (opción recomendable).
• FALSE: Está activado, se puede inyectar código.

NOTA: Corregida esta entrada, estaba al revés

Para más información se puede consultar la nota 163305.1 del metalink. También en http://www.red-database-security.com/wp/sql_injection_forms_us.pdf se puede obtener más información.

Asignar una función la tecla escape en Forms10g

Una utilidad de la tecla ESC (Escape) y muy utilizada en muchas aplicaciones es la de cerrar la ventana abierta. Esta operación se puede configurar en Forms 10g editando el archivo frmweb.res y añadiendo la siguiente línea:

27 : 0 : "Escape" : 32 : "Salir"

• 27: es el identificador "Java function number" asignado a la tecla escape.
• 0: Indica el "Java modifiers number" es decir, qué combinación de teclas más la Escape se pulsarán para ejecutar el evento, el 0 quiere decir que no se utilizará en conjunto con otra tecla, si se pusiese 1 para ejecutar el evento habría que pulsar Mayúsculas+Esc, con 2 haríamos referencia a la tecla "Control", con 8 a la tecla "Alt". .
• "Escape": Es un texto asignado por el usuario, no afecta al funcionamiento.
• 32: es el identificador "Forms function number" que indentifica la operación que debe se debe de ejecutar en Forms. El 32 indica que se ejecutará KEY-EXIT.
• "Salir": Es un texto asignado por el usuario, no afecta al funcionamiento.

El archivo fmrweb.res se encuentra en $ORACLE_HOME/forms/admin/resource/

En caso de configurar el servidor de aplicaciones en UTF8 se utiliza el archivo fmrweb_utf8.res.

Se considera que el servidor de aplicaciones está en UTF8 cuando en el archivo indicado en la entrada envFile del archivo formsweb.cfg tiene definida la siguiente variable:

NLS_LANG=Spanish_Spain.UTF8

Configurar Oracle XE para que conecte correctamente Forms 6i

Por defecto Oracle XE se instala con el juego de caracteres AL32UTF8, con ese juego de caracteres el cliente de Oracle Forms 6i no conecta con la base de datos, para migrar ese juego de caracteres a UTF8 puro debemos de ejecutar lo siguiente:

sqlplus /nolog
SQL> connect / as sysdba
Conectado.
SQL> shutdown immediate
SQL> startup restrict
SQL> alter database character set internal_use UTF8;
SQL> shutdown immediate
SQL> startup

Hay ciertos índices que Oracle si existen no puede realizarse la conversión ya que dará el siguiente error:


ORA-00604: error occurred at recursive SQL level 1
ORA-54028: cannot change the HIDDEN/VISIBLE property of a virtual column

Podemos ver los índices incompatibles mediante esta SELECT:

SELECT owner, index_name, index_type, table_owner, table_name, status, funcidx_status

  FROM all_indexes

 WHERE index_type NOT IN ('NORMAL', 'BITMAP', 'IOT - TOP')

   AND table_name IN (SELECT UNIQUE (table_name)

                        FROM dba_tab_columns

                       WHERE char_used = 'C');

Hay que borrarlos y luego volver a crearlos una vez convertido a UTF8.

Problemas de rendimiento de Forms10g con antivirus NOD32

El antivirus NOD32 tiene activado por defecto la opción analizar todo el tráfico HTTP, lo que hace ralentizar tremendamente el funcionamiento de las aplicaciones en Forms 10g (por lo menos en la versión 4.0.314.0).

Para desactivar ese control hay que abrir NOD32, ir a Configuración, pinchar en "Muestra las opciones avanzadas de configuración" y en la sección "Antivirus y antiespía" -> "Protección del tráfico de Internet" -> "HTTP, HTTPS" y desactivar la check "Activar el análisis HTTP".

Evidentemente es un fallo de NOD32 ya que Forms10g por defecto usa el puerto 7778 y los puertos que en teoría analiza por defecto son los 80, 8080 y 3128. Además si configuramos excluir algunas direcciones no soluciona nada, la única opción es desactivar totalmente el análisis http.

Formas de cargar un List Item por código

Directamente desde una sql

El proceso se basa en un grupo de registros que creamos en base a una sql dinámica "v_grupo := Create_Group_From_Query('RecorG', v_sql);", para cargar la lista de elementos en base al grupo usamos la instrucción "POPULATE_LIST".

Cuando creamos el ítem del bloque podemos dejarlo sin ningún valor, pero nos va a dar una advertencia de compilación un poco molesta, pero totalmente inocua. Si queremos que no nos dé, simplemente abrimos los elementos de lista y en el primer elemento le quitamos el campo "Valor de elemento de Lista" y como el valor por inicial es NULL y ese elemento es NULL no nos va a protestar.

Ejemplo:

DECLARE
v_sql VARCHAR2(200); -- Variable para construir la SELECT dinánica.
v_grupo RecordGroup; -- Variable en donde vamos a meter el grupo de registros temporalmente.
v_estado_empresa ESTADOS.CODIGO%TYPE := 'ESPA'; -- Variable que contiene el valor que queremos mostrar por defecto.
BEGIN
/*
Construimos la SELECT. En el primer campo sacamos
lo que queremos que muestre la lista y en el segundo
campo el valor correspondiente que va a devolver
por la selección (normalmente un código).*/

v_sql := 'SELECT INITCAP(nombre), codigo FROM estados ORDER BY nombre';

-- Asignamos el resultado de la select al grupo de registros.
v_grupo := Create_Group_From_Query('RecorG', v_sql);

-- Construimos la lista, siempre y cuando la select devolviese registros.
IF POPULATE_GROUP(v_grupo) = 0 THEN
POPULATE_LIST('B1.ESTADO', V_Grupo);
END IF;

-- Borramos el grupo, liberamos memoria que ya no nos hace falta.
DELETE_GROUP(v_grupo);

-- Asignamos el valor por defecto que queremos.
:b1.estado := v_estado_empresa;

-- Si el campo es obligatorio deberíamos de poner esto para que nos elimine el elemento en blanco.
Set_Item_Property('B1.ESTADO', REQUIRED, PROPERTY_TRUE);
END;

Elemento a elemento

Para limpiar un List-item se hace con la instrucción CLEAR_LIST('BLOQUE.CAMPO');

Para ir añadiendo elementos se hace con ADD_LIST_ELEMENT('BLOQUE.CAMPO', , , );

* : Será un número que identifica cada elemento, se comenzará a numerar en el 1.
* : Texto que visualizará en el desplegable el usuario.
* : Valor que toma el campo cuando se selecciona.


Ejemplo:


DECLARE
CURSOR cur_clientes IS
SELECT codigo_rapido, nombre
FROM clientes;

v_indice NUMBER;
v_primer_cliente CLIENTES.CODIGO_RAPIDO%TYPE;
BEGIN
Set_Item_Property('B1.CLIENTE', REQUIRED, PROPERTY_FALSE);
CLEAR_LIST('B1.CLIENTE');

FOR reg IN cur_clientes LOOP
v_indice := v_indice + 1;
Add_List_Element('B1.CLIENTE', v_indice, reg.nombre, reg.codigo_rapido);

IF v_primer_cliente IS NULL THEN
v_primer_cliente := reg.codigo_rapidol;
END IF;
END LOOP;
:b1.cliente := v_primer_cliente;
Set_Item_Property('B1.CLIENTE', REQUIRED, PROPERTY_TRUE);
END;