Usar triggered view en Access

En el artículo anterior vimos las reglas para diseñar un trigger SQL. Ahora consideraremos reglas de diseño adicionales para escenarios en los que queremos usar una vista con un activador como fuente para un formulario de Access. El uso de una vista activada le permite diseñar un formulario de entrada de datos enlazado que de otro modo podría no ser posible. Por ejemplo, podemos apoyar:

  1. Entrada de datos desnormalizados
  2. Inserts de múltiples tablas
  3. Reglas de validación complejas, especialmente aquellas que involucran otras tablas

y pocos mas. Podemos lograrlos utilizando un formulario de Access ilimitado o un formulario de Access vinculado basado en una tabla de acceso temporal. Sin embargo, la experiencia ha sido que un formulario ilimitado o un formulario temporal basado en tablas requiere mucha más programación para configurar, validar y enviar los datos. Además, un cambio en el esquema siempre requeriría una actualización de la aplicación front-end, incluso si los cambios no aplicaban la entrada de datos al formulario.

Esa es una de las muchas razones por las que prefiero mantener la lógica cerca de los datos, y una vista activada nos ayuda a mantener la lógica en la misma capa, lo que nos permite manejar los cambios en el esquema fácilmente. Sin embargo, para usar una vista activada se requiere una comprensión más profunda de cómo funciona Access y de esto derivaremos.

¿Qué hace Access detrás de escena?

La clave para usar vistas activadas es saber qué hará Access detrás de escena. Cuando interactúa con un formulario vinculado a una tabla vinculada desde una fuente de datos ODBC, compondrá una declaración SQL ODBC que corresponda a las ediciones del usuario. Esto significa que cada vez que un usuario agrega un nuevo registro al formulario enlazado, Access enviará una declaración INSERT. Del mismo modo, si el usuario modifica un registro existente, enviará una declaración de ACTUALIZACIÓN y, al eliminar un registro, la declaración DELETE. Comenzaremos con la instrucción INSERT, ya que necesitamos ver cómo maneja la población de claves principales.

INSERTAR declaraciones

Supongamos que tenemos una tabla con 5 campos expuestos como cuadros de texto en el formulario enlazado y todos son opcionales. Cuando el usuario crea un nuevo registro, ingresa datos en solo 2 campos, dejando los otros 3 campos en blanco, Access redactará una declaración ODBC SQL similar a esta:

Tenga en cuenta que al omitir fieldThree, fieldFour y fieldFive, Access garantiza que el servidor puede proporcionar los valores predeterminados para esos campos, independientemente de cuál sea el valor predeterminado. De esa declaración, es bastante razonable. Sin embargo, esto no proporciona a Access ningún comentario del servidor sobre lo que necesita proporcionar en el formulario. Por esa razón, Access necesita hacer un seguimiento inmediato con una instrucción SELECT para recuperar la instrucción recién insertada. Si pretendemos que fieldOne es una clave principal, Access compondrá una instrucción SELECT de esta manera:

Podríamos esperar que fieldOne esté en la cláusula WHERE ya que es la clave principal, pero ¿por qué Access incluyó fieldTwo? El razonamiento es que, dado que el usuario ingresó 123, debería aparecer como 123. Por lo tanto, si el servidor devuelve un valor diferente para fieldTwo, Access asumirá que el registro fue cambiado por otra persona y, por lo tanto, mostrará un mensaje al usuario que ese registro obtuvo cambiado mientras estaban ahorrando.

Pero aún no hemos terminado. Esta fue una configuración simple donde el usuario ingresa manualmente la clave primaria, lo cual es muy raro. Más comúnmente, podríamos estar usando un servidor sustituto oculto donde esperábamos que el servidor se generara automáticamente, generalmente con el atributo IDENTITY. Si suponemos que la tabla ahora tiene un campo llamado ID que es una columna IDENTITY, Access ejecutará las siguientes declaraciones:

Access verificará primero que no se crearon registros con NULL como el nuevo valor de la clave primaria. Por supuesto, por definición, la clave primaria no puede ser nula, por lo que no recuperamos registros. Access luego enviará otra declaración que es específica de SQL Server:

que luego se sigue con la siguiente declaración:

Access proporcionará el valor que obtuvo de la consulta de @@identity ejecutada antes de la consulta para el campo ID. Como antes, también especificará los valores que el usuario editó, nuevamente para evitar cambios inesperados.

QUE HACER:

1) proporcione ejemplos de lo que Access hace detrás de escena
2) muestra cómo crear #Deleted y por qué sucede
3) hable acerca de incluir la versión de fila
4) hablar sobre los cambios en los datos (por ejemplo, los cambios del usuario y los cambios del disparador) y el impacto que tiene en Access
5) hable sobre cómo el pseudo-índice en la tabla vinculada de acceso afecta cómo Access actualiza la tabla

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*