Blog

Eventos de tabla

V7 cuenta con una serie de eventos de tabla que usaremos para solucionar las casuísticas que no puedan ser resueltas a través del uso de la estructura de datos, es decir, con la ayuda de punteros (maestro, singular, indirecto, etc.) y actualizaciones que deben ser siempre nuestra primera opción, si es posible.

Los eventos de tablas son procesos definidos para que se ejecuten automáticamente al producirse el evento al que hacen referencia. Éstos pueden ser:

Anterior, Interno o Posterior a un alta, Anterior, Interno o Posterior a una baja, Anterior, Interno o Posterior a una modificación de ficha.

Eventos de tabla 1

Los Eventos de tablas se crean pulsando el botón (Nuevo evento de tabla) en la barra de herramientas del editor central cuando se tenemos editada una tabla. Al pulsarlo se muestra la ventana «Nuevo evento de tabla.

Eventos de tabla 2

A continuación elegimos el tipo de evento que vamos a editar y éste se incorpora a la lista de procesos de la tabla. Una vez que lo hemos creado, pulsamos Intro o hacemos doble clic sobre el proceso, desde el inspector de objetos y entramos en la ventana de edición de procesos, que llevará por título «Nombre de la tabla: Alta, Baja o Modificación: Tipo de evento». El Editor de Instrucciones es igual que la de un objeto Proceso, excepto por que el origen y destino ya están fijados (debe ser una ficha de la tabla que estamos editando).

Eventos de tabla 3

El orden de ejecución que llevan los distintos eventos junto con las actualizaciones es el siguiente:

» Proceso Anterior

» Alta, Baja o Modificación

» Proceso Interno

» Actualización

» Proceso Posterior

Primero se ejecuta el proceso anterior, en él es donde podemos realizar tareas de control con el fin de cancelar o seguir adelante con el alta, modificación o baja.

A continuación se produce la acción propiamente dicha, Alta, Baja o Modificación.

Después se lanza el proceso interno, que normalmente usaremos para calcular y verificar las condiciones que luego determinarán la actuación de las actualizaciones. En este punto ya podremos leer datos como el código, campos calculados, etc., pero aquí ya no podremos realizar modificaciones en los campos del registro. Por lo tanto, si necesitamos modificar el contenido de un campo del registro actual, debemos hacerlo en uno de los procesos asociados a los eventos anteriores a Altas, Bajas o Modificaciones. Esto es así, porque en los procesos internos ya se ha realizado el evento, luego no cabe modificación alguna. Sin embargo, en los procesos sí tendremos disponibles funciones que provoquen escritura en disco, pero para ello tendremos que cargar el registro que queramos modificar antes de realizar la operación.

Se produce entonces la actualización, que realizará las modificaciones definidas por el subobjeto en otras tablas enlazadas.

Por último se produce el proceso posterior. Cuando programamos debemos tener en cuenta que en los procesos posteriores al evento no es posible modificar los datos del registro en curso, tal y como ocurre con el proceso interno. La diferencia entre el proceso posterior al evento y el interno es que ya tenemos en cuenta las actualizaciones que se han producido en otras tablas.

NOTA: No debemos incluir en este tipo de procesos nada que implique la intervención del usuario, por ejemplo mostrar un formulario, una pregunta, petición de un dato, etc. El motivo, como en otros casos, es que este tipo de operaciones se llevan a cabo en el vServer, por lo que el mensaje o el formulario no serían presentados en el Cliente, sino en el propio Servidor. Si en un evento de tabla incluyésemos algo que implicase la intervención del usuario, sería obviado por el Servidor.

18 thoughts on “Eventos de tabla

  1. Hola.

    Básicamente, como en V6.x, y por eso:

    – Sería interesante contar con el valor anterior de los campos que cambian al modificar (al estilo SQL Server)

    – La función de proceso «Ha cambiado el campo» ¿funciona en todos los eventos, tanto anterior como interno o posterior?

    Gracias,

    Fran Varona

  2. Apoyo la sugerencia de abajo.

    Sería muy interesante conocer el valor de los campos antes de realizar el cambio, nos permitiría incluir un sistema de control de autoría, volver atrás los contenidos, actualizar otras tablas con los valores anteriores, etc.

    Un saludo.

  3. Hola,

    Aparte de apoyar lo que dice Fran Varona, quería comentar que si el Evento (o trigger) se considera componente de la caja de DATOS o de OBJETOS.

    Es decir, si se hereda una caja de datos, se hereda con eventos o sin ellos?? Imagino que irán en la caja de datos y que si se heredarám, pero creo recordar que al principio de toda esta andadura de V7 hubo algo «raro» relacionado con esto. Por eso pregunto …

    Mucahs gracias y un saludo.

    Carlos Abella (AXOS)

  4. Estimado Carlos:

    Los eventos o triggers son subobjetos del objeto Tabla. Las tablas únicamente se pueden crear en cajas de datos, por supuesto, por lo que el evento, que es indisociable de la tabla, pertenece a la caja de datos. Por lo que si heredamos una caja de datos con tablas que tienen eventos, por supuesto que los eventos serán ejecutados al hacer uso de las tablas que contiene la caja.

    Se trata precisamente de independizar el funcionamiento de las cajas de datos que sean autónomas y no requieran de las cajas de aplicación para funcionar de forma completa. Además garantizamos de esta forma que las cajas de datos actuarán de igual forma si definimos todas las operaciones en la caja, aún estando heredadas por distintas cajas de aplicación.

    Cuando queramos que ciertas operaciones con los datos se realicen siempre, independientemente de la caja de aplicación que haga uso de la de datos, definiremos esas operaciones en la caja de datos. Si dependen de la caja de aplicación, entonces podremos hacer que sea en la caja de aplicación donde se realicen, o hacer que sean opcionales en la caja de datos.

    Un comentario en cuanto a la terminología, para no os confundamos con nuestras explicaciones: Las cajas de objetos son de dos tipos: cajas de datos y cajas de aplicación. Las cajas de datos contienen los objetos y subobjetos que definen la estructura. Las cajas de aplicación contienen los objetos y subobjetos que definen el interfaz de la aplicación y que operan con las cajas de datos.

  5. Dentro del orden de ejecución que llevan los distintos eventos, ¿cuando se calculan los contenidos iniciales de los campos?, Para éste cáculo, ¿se sigue el orden o posición de los campos en la tabla?.

  6. Hola Cyf,

    El contenido inicial de los campos es previo a cualquier evento de la tabla y si se calcula en el orden fisico de los campos en la tabla.

    El contenido inicial se calcula siempre que varíe algún elemento de la formula que lo define por eso es indiferente el orden en que esten los campos ya que si un campo previo, en orden físico a otro del que depende su contenido inicial, se calculará siempre que el posterior varie su valor.

    Hay que evitar redundancias donde el contenido inicial de dos campos dependa el uno del otro y viceversa. Esto provocará un bucle infinito.

    Creo que estas mezclando los contenidos iniciales con el orden de los capilares de los tubos. Donde si es importante el orden de los capilares para el valor final de los campos. Si tras modificar un campo con el valor que deseamos en un capilar, modificamos otro campo que este en el contenido inicial del anterior, alteraremos el valor obteniendo resultados no esperados.

    Saludos.

  7. SUGERENCIA V7.

    Hola ya que sale en tema de los tubos y los contenidos iniciales, aprovecho para poner una sugerencia:

    Poder, en procesos que utilicen tubos de ficha o altas directas, elegir si queremos que utilizar el contenido inicial en campos destino e incluso las actualizaciones. Algo como los estilos que existen para los tubos de lista.

    Es importante, porque cuando realizas altas directas, en procesos, dando contenido a todos los campos, resulta que tienes que estar muy pendiente de hacerlo en un orden que no provoque resultados inesperados.

    Nacho

  8. Hola Nacho,

    Muchas gracias por tu sugerencia, tomamos nota para evaluarla.

    En un principio lo veo poco lógico, ya que tienes que ver un tubo de ficha como un Alta directa. No tiene mucho sentido configurar un contenido inicial en el diseño de los campos para luego inactivarlo en las altas de ficha.

    De todos modos siempre se puede utilizar el tubo de lista, para uno o más elementos. La lógica que tiene tener estas opciones en los tubos de lista es la de optimizar el rendimiento en las altas de muchos registros y la de ejecutar importaciones o traspaso de datos que queremos reflejar con exactitud.

    Respecto del orden a la hora de modificar campos, no solo lo hay que tener en cuenta en los capilares de un tubo de ficha, también lo hay que tener en cuenta en todas las altas y modificaciones que se hagan de la ficha, ya sea desde proceso o incluso desde formularios de ejecución. Te pondré un ejemplo a ver si me explico:

    Diseñando un formulario de direcciones donde el puntero a país tiene contenido inicial el de la localidad, debemos poner primero el control de la localidad y luego el de país, ya que si primero se introduce un país y luego se localiza una localidad de otro país, no servirá de nada el primer país seleccionado. De lo contrario si queremos poner primero el control del país deberemos tener en cuenta esta circunstancia par subindexar la localidad y filtrar el localizador.

    Un saludo.

  9. Hola Alejandro,

    Entiendo que en los tubos de ficha puedes poner tu el orden que deba llevar, pero tu piensa que cuando incorporamos datos desde ficheros externos (TXT, XML), donde nos vienen todos los campos, atender al orden es complicado.

    El caso donde me sucede, y tengo que estar muy atento cada vez que añado campos es el siguiente.

    Tengo un fichero XML con el formato:

    valor1valor2……

    Yo recorro los tags por el numero de campo de la tabla

    El proceso sería:

    Alta directa

    for c, 1, «c» < NroCampos Set Valor, DATO-ENTRE-TAGS APIVEL Modificar campo por numero, "c", "Valor" Voy a modificar todos los campos, con los valores del fichero, no me interesan valores por defecto. El problema es que como el campo número 5, modifique el valor del campo número 2, ya me ha fastidiado. Por lo que me obliga a tener mucho cuidado con el orden de los campos en la tabla, y establecer esto en función de los valores por defecto de los demás y no por otros criterios mas lógicos (y no siempre es facil). A lo mejor podía cuando acabas de modificar (en el mismo acto del alta), el valor de un campo no saltar el valor por defecto, o tener una función en procesos que inhabilite el contenido inicial, y otra que lo vuelva a habilitar. Es una idea Nacho

  10. Hola Nacho,

    Ya te comente que tomamos nota de la sugerencia, el departamento de desarrollo evaluará su implementación. El resto de comentarios eran un poco como lo veo yo. Lo que voy a hacer es sugerirte un par de opciones para el sistema que tienes montado actualmente en Velneo 6.x:

    1º) Importación a tabla temporal: consistiría en que todas las importaciones de los ficheros XML las realices inicialmente a una tabla auxiliar, que puede ser en memoria o no según las circunstancias. Esta tabla la podrás utilizar para distintas importaciones, para lo que estará compuesta de campos sin ningún tipo de contenido inicial y de todos los tipos que necesites, alfabéticos, numéricos, booleanos, objeto, etc. Tras realizar todas las altas en dicha tabla auxiliar solo tienes que realizar un tubo de lista de los registros importados hacia la tabla de destino en cada caso. En los tubos de lista sí que puedes desactivar los contenidos iniciales y actualizaciones. Con este método te puedes olvidar definitivamente de valorar si un nuevo campo afecta al contenido de otros y del orden de alta en la importación.

    Este sistema tiene otras ventajas como realizar las altas en una única transacción evitando problemas de importaciones parciales o el que lo tengas que controlar tu a la hora de realizar las altas.

    2º) Quitar los contenidos iniciales: si el contenido inicial de un campo, no es válido en todos los casos, hay que valorar si es correcto tener un contenido inicial en ese campo. Es decir: si las altas se realizan por importación, donde no nos interesan los contenidos iniciales, y manualmente por medio de formulario, donde sí nos interesan los contenidos iniciales, debemos valorar si nos interesa realizar el contenido inicial por medio de un proceso en la perdida de foco del control correspondiente al campo que define el contenido.

    Por ejemplo, si la importación de ficheros XML se trata de una carga inicial de datos, puede interesarte aplicar el primer método, en cambio si se trata de un carga habitual de tarifas de productos puede resultar más adecuado el segundo método.

    Saludos.

  11. Hola, gracias por las sugerencias.

    El primer método no está mal, sobre todo para casos poco frecuentes. Estudiaréi en que situaciones me puede venir bien. Pero en mi caso son muchas tablas y cargas continuas. Son sincronizaciones entre centros de trabajo, muchas tablas y muy frecuentes.

    El segundo método ya lo había pensado y en algunos casos lo aplico, pero en la mayoría, me resulta una solución mas costosa (todo lo que puede estar en el lado izquierdo no debe estar en el derecho).

    Gracias. Un saludo

    Nacho

  12. Buenas, 
    Estoy tratando de hacer un par de cosas en un evento de tabla y tengo algunas dudas.
    1) El proceso se esta ejecutando en modo servidor, ok! Debo cambiar el directorio por defecto y no lo consigo , solo me toma el cambio con unidades locales de cliente y yo lo tengo que usar una unidad del servidor.
    2) La otra duda es : Si tengo un proceso que hace toda una importación («Ejecuta una aplicación que genera un txt, abro el Txt y lo guardo en una tabla de disco») todo eso en modo local en cliente funciona y ejecutado con la nueva modalidad de Objeto. La pregunta es deberia funcionar si creo el manejador en el evento de tabla y lo disparo desde ahi mismo?????
    Gracias 
     
    Ale

  13. Buenas otra vez por aca.
    Obtuve el siguiente mensaje en el vAdmin:  Instrucción sin programar: Disparar objeto ( LEERCTA, 1º plano: Local, OK,  )
    Tienen idea de por que ?
     
    Gracias
    Ale

  14. Hola Alejandro,

    El lugar adecuado para plantear dudas y consultas sobre programación Velneo V7 es el foro.

    Lo mejor que puedes hacer es escribir estas dudas en el foro al que puedes acceder desde la barra de menús superior, opción foros.

    Gracias por tu colaboración.

    Saludos.

Dejar un comentario