Hemos implementado en V7 los Triggers o Eventos de tabla. Hemos hecho un lavado de cara a nuestros amigos ejecutables y aprovechamos para ordenarlos por tipo y evento, es decir, quedarán de la siguiente manera:
- Anterior a un alta de ficha
- Interno a un alta de ficha
- Posterior a un alta de ficha
- Anterior a una modificación de ficha
- Interno a una modificación de ficha
- Posterior a una modificación de ficha
- Anterior a una baja de ficha
- Interno a una baja de ficha
- Posterior a una baja de ficha
Tendremos que ir creándolos a medida que los necesitemos, tratándose como subobjetos del objeto tabla, al igual que actualizaciones, índices, componentes de índices, etc., pero tendrán un número limitado, claro está, uno de cada tipo, por lo que no se repetirán.Por otro lado, esto nos lleva a tener que contemplar una cierta problemática: los objetos visuales no viajan con la caja de datos, ni éstas últimas heredan cajas de objetos visuales. Sin embargo, los triggers pueden hacer uso de objetos visuales puesto que al fin y al cabo tienen disponibles las mismas instrucciones que los procesos. Una práctica habitual es que el trigger no contenga nada más que una llamada a un proceso y que sea en éste donde programemos todo, para poder reutilizarlo en otros eventos.Veremos cómo resolver esto, puesto que es una problemática que se repite, por ejemplo en tablas estáticas donde se necesitan iconos, en punteros indirectos, donde se definen formularios para altas, etc.Como posibles soluciones: en el caso del puntero indirecto, por ejemplo, lo que podríamos hacer sería que la selección del formulario que se muestre en el caso de un alta se haría en el formulario donde se llama al puntero indirecto (tal y como lo permite un botón de alta asociado a un control de edición) y no en el propio campo que es donde se hace ahora.Lo que haremos también es permitir que ciertos objetos, como el objeto Proceso, puedan guardarse en una caja de datos. De esta manera podemos seguir usando estos objetos pero sin depender de la caja de objetos visuales y, por tanto, de la interacción del usuario. Convendréis con nosotros en que un proceso de la caja de datos no puede esperar por una acción del usuario final.Esto es sobre todo porque nuestra intención es que las cajas de datos sean autónomas, autosuficientes, independientes del usuario final, para que sean más seguras aún si cabe, y garantizar su aislamiento, para que no se vea en ningún caso comprometida la integridad de los datos y proteger vServer.Por último, y no por ello menos importante, al contrario, a resultas de este tratamiento, de que la caja sea autónoma y aislada, y del funcionamiento de la herencia, podemos estar seguros de que cuando varias cajas heredan cierta caja, todas trabajarán con esa misma caja de igual forma, ya que tendrá no sólo todos los triggers, si no que tendrá todos los maestros y tablas enlazadas (tablas estáticas, hermanos contiguos, etc.), campos, índices, actualizaciones e históricos, por lo que también estamos garantizando la integridad en el ámbito de la herencia.Por tanto podremos olvidarnos de controlar que estemos modificando el proyecto correcto, de copiar las tablas modificadas en los proyectos que las comparten, de añadir en cada proyecto todos los maestros y tablas enlazadas y eliminar los enlaces históricos que no existen en los proyectos de destino, etc.
