Estoy empezando con Velneo y en mi primera App que estoy desarrollando he copiado el tema de los permisos de usuario de vBase, todo me funciona perfecto, pero tengo una duda y no sé o no veo cómo resolver.
Cuando entro en la tabla de grupos de usuarios y hago doble click sobre un grupo para añadirle o quitarle permisos, se me abre otro formulario con dos rejillas, los permisos que tengo y los que puedo añadir, pero si añado o Quito y luego pulso el botón “cancelar” me sigue guardando los datos y no sé como hacer para que se quede como estaba.
Te guarda los cambios por que realmente está modifcando la tabla que relaciona Grupos-Permisos.
Te cancela si haces un cambio directo sobre la tabla de grupos.
El boton Cancelar de Velneo, no es “mágico”, es decir, no siempre cancela…
Me explico mejor…
La accion “Interfaz: Cancelar”, aplicada a un formulario, lo que hace mas o menos es “cierra el formulario y no guardes la ficha”. He dicho la ficha, es decir, la ficha principal del formulario.
SI HACEMOS CAMBIOS EN OTRAS TABLAS, NORMALMENTE HISTORICAS, ESOS CAMBIOS JAMAS SERAN “MAGICAMENTE” ANULADOS POR EL BOTON CANCELAR.
ADEMAS, VELNEO GUARDA AUTOMATICAMENTE LAS FICHAS EN ALGUNAS CIRCUNSTANCIAS (1), EN ESTOS CASOS EL BOTON CANCELAR NO FUCIONARA, PUES LA FICHA YA SIDO GUARDADA.
EL BOTON CANCELAR HACE “NO GUARDES MI FICHA CON LOS CAMBIOS PENDIENTES DE GUARDAR” Y NO HACE “ANULAME TODOS LOS CAMBIOS YA GUARDADOS EN ESTA TABLA O EN CUALQUIER OTRA”.
(1) Ejemplo tipico: si haces cambios en un padre (cabecera de factura, por ejemplo) y sin guardarlo, intentas añadir un hijo (linea de factura), automaticamemnte Velneo guardara la ficha del padre antes de dar el alta del hijo. Si ahora usas el boton Cancelar con la idea de cancelar el cambio en la cabecera, no funcionara PUES EL DATO YA SIDO GUARDADO. Y muchisimo menos te cancelara los cambios hechos a las lineas de factura.
Si quieres un boton Cancelar que haga todas esas maravillas, ya puedes empezar a programarlo por tu cuenta.
El Cancelar en formularios de Velneo funciona asi, y seguro que por buenas razones.
El proceso PED_CM_REFRESCAR_PDTES_3P de la línea que comentas, dispara en 3º plano la búsqueda BUSCAR_PEDIDOS. Lo que se pretende es ejecutar la Búsqueda siempre en 3º plano y en Velneo hay que hacerlo mediante un proceso intermediario que nos permita cambiar el cálculo de la máquina del Cliente a la del Servidor.
Hola victorgt.
La Acción de Velneo “Interfaz: Cancelar” hace correctamente lo que tiene que hacer, es decir, cancelar todo aquello que está en memoria, sin confirmar todavía en la base de datos. Sería de locos intentar cancelar todo aquello que ya se haya grabado en la base de datos.
El problema del formulario Maestro-Detalle es que desde un principio Velneo se empeña en mostrar este ejemplo en los cursos básicos, sin explicar antes a fondo el funcionamiento de las transacciones en la Base de datos Real de Velneo. Yo también alucinaba los primeros días con los cursos básicos de Velneo, donde veía que se creaban maestros automáticamente y no se explicaba el porqué ni el cómo.
Bien, pues la clave está en entender el sistema transaccional de Velneo, algo que debería estar en el programa del curso básico, pero no.
Pequeño resumen:
Las Listas y Fichas de Velneo siempre deben contener registros que existan realmente en la tabla.
Velneo abre y cierra las transacciones automáticamente.
Para controlar las transacciones manualmente tenemos los comandos “Forzar transacción” y “Deshacer transacción”.
Los formularios en modo Vista (con pestaña) se abren siempre por defecto en modo bloqueo blando, es decir, la transacción no se ejecuta hasta que el usuario pulsa el botón <Aceptar>, y en ese momento es cuando se guardan los datos de la ficha en memoria en la tabla física. Si otro usuario ha modificado los mismos campos antes que nosotros, perderemos los cambios realizados en dichos campos, el que primero guarda en disco es el que se lleva el gato al agua.
Todos los cambios que se hagan en otros registros de la misma tabla o tablas relacionadas se confirmarán siempre en la base de datos tan pronto como se realizen, sin esperar al comando <Aceptar>. Por supuesto podemos controlar esos cambios mediante procesos transaccionales.
Lo que tiene que quedar claro es que el botón <Cancelar> solo deshace los cambios de la Ficha del formulario, nada más.
Podemos forzar la apertura de un formulario con Bloqueo Duro. Esto es una forma de decir que el formulario abrirá una transacción en el vServer desde la ficha de entrada y todo lo que se haga a partir de entonces en toda la base de datos quedará bloqueado para modificación del resto de instancias de la Aplicación. Es como enviar un Forzar Transaccion a la base de datos y esperar hasta que reciba un COMMIT o ROLLBACK. El COMMIT lo haremos con el botón <Aceptar> y el ROOLBACK con el botón <Deshacer>.
Ahora viene lo interesante y que tampoco se explica en los cursos básicos. Todo Proceso o Actualización se ejecuta siempre con Bloqueo Duro. Cualquier modificación en la base de datos abrirá automáticamente una Transacción en el vServer y todas las sucesivas modificaciones quedarán englobadas en dicha transacción. Además el acceso a modificar del resto de instancias quedará imhabilitado mientras dure el proceso o actualización.
Entonces ¿Cómo solucionamos el tema de Maestro-Detalle y la cancelación de cambios? 2 opciones:
1º - Abrimos el formulario en modo Vista y estilo Bloqueo Duro
2º - Ejecutamos un proceso que abra manualmente una transacción para forzar el Bloqueo Duro
En este caso observad que el formulario siempre se ejecutará en ventana de diálogo
// Abre manualmente una Transacción. Verlo en el vAdmin
Forzar transacción
Crear manejador de objeto ( oCabecera, Formulario FRM_CABECERA_CON_LINEAS@0PS_Ejercicios_app )
Disparar objeto ( oCabecera, No aplicable, LOK )
Libre
If ( LOK = 0 )
// El Usuario ha rechazado todos los cambios con el botón <Cancelar>
Deshacer transacción
Mensaje ( “Transacción deshecha”, Información, , )
Finalmente aclarar que un proceso no abrirá transacción (o lo que es lo mismo Forzar transacción) hasta que se ejecute un comando de modificación de datos, por eso en el ejemplo anterior hemos usado el comando Forzar transacción ya que no hay ningún comando previo que modifique datos.
¡¡OJO!! no es conveniente dejarle al usuario un formulario abierto con Bloqueo Duro ya que puede a su vez bloquear el trabajo de muchos usuarios concurrentes. Por esta razón es poco probable ver este diseño Maestro-Detalle en las aplicaciones reales.
Saludos y espero haber aclarado algo este tema.
Paco Satué
Paco buen día estoy revisando estos temas de transacciones, y vi este articulo, yo estoy implementando con el #OFF=1 activado y en un trigger al darle aceptar previamente le pongo guardar en otro boleano, entonces los marca como #OFF=0, la idea es que si desiste o se queda colgado o lo que sea, queda la evidencia de sus registro y si decide cancelar tanto cabecera y detalle no afectan ni mis actualizaciones.