Blog

Formularios: Bloqueo blando y bloqueo duro

Formularios: Bloqueo blando y bloqueo duro 1En formularios, por defecto, existe lo que llamamos bloqueo blando, es decir, si dos usuarios editan la misma ficha, modifican y aceptan cambios, si no hay colisión (es decir, si han modificado campos diferentes) se funden las modificaciones de ambos. Si hay colisión, es decir, si modifican un mismo campo, el valor que mantenga la ficha en ese campo será el del usuario haya guardado la ficha en primer lugar. La versión 7.3 incorpora una novedad en la edición de fichas mediante formulario: El bloqueo duro.


Se trata de una propiedad del objeto formulario que, en caso de activarla, bloqueará el registro editado en ese formulario, provocando el inicio de una transacción y lo bloqueará en exclusiva en modo lectura/escritura hasta que finalice esa transacción. Eso tiene varias implicaciones:

  • Dado que la edición de la ficha implica el inicio de una transacción, todas las operaciones de lectura/escritura derivadas de la edición de esa ficha (actualizaciones, modificación de históricos desde una rejilla incluida como control objeto del formulario, etc.) quedarán englobadas en la misma, por lo que si la transacción es deshecha, se desharán todas las operaciones de escritura realizadas tanto directa como indirectamente desde ese formulario.
  • Todas las fichas modificadas directa o indirectamente desde el formulario serán también bloqueadas, por lo que tampoco podrán ser modificadas por otros usuarios o procesos. Esto es algo que debemos tener muy en cuenta a la hora de decidir si realizar o no un bloqueo duro en un formulario.
  • Mientras el formulario permanezca abierto la ficha podrá ser leída por otros usuarios desde otros formularios que no tengan activado el estilo bloqueo duro o desde otros procesos, pero no podrá ser modificada; al contrario de lo que sucede en el bloqueo blando, en el que dos usuarios pueden editar un mismo registro mientras los campos que modifiquen sean distintos.
  • Mientras el formulario permanezca abierto, si otro usuario intenta editar esa misma ficha con un formulario que tenga activado el estilo bloqueo duro, no podrá editarla ya su apertura iniciará la transacción para bloquearlo, pero, como ya se encuentra bloqueado, no podrá continuar con la transacción.

El bloqueo duro equivale a la ejecución de un proceso transaccional en el que se use el comando de instrucción de proceso Pedir formulario o el comando Modificar ficha seleccionada con formulario, donde todos los registros modificados en la transacción permanencen bloqueados para otros usuarios mientras ésta dure.

Nuestra recomendación es utilizar por defecto el bloqueo blando y usar el bloqueo duro en formularios en los que el usuario no pueda generar bloqueos indiscriminados de registros.

En ese tipo de formularios, para cancelar la modificación dispondremos de dos comandos de botón:

Cancelar/Cancelar controlado: Si usamos este comando se cancelarán solamente las modificaciones realizadas en la ficha editada y no aseguradas en disco. Las modificaciones realizadas en otras fichas, en plurales o registros maestros actualizados por ejemplo, no serán deshechas, salvo, claro está, aquellas actualizaciones en las que intervenga el campo o campos cuya modificación será cancelada.

Deshacer/Deshacer controlado: Si usamos este comando se deshará la transacción, es decir, que se desharán todas las operaciones de escritura realizadas tanto directa como indirectamente desde ese formulario. Este comando equivale al comando de instrucción de proceso Deshacer transacción.

9 thoughts on “Formularios: Bloqueo blando y bloqueo duro

  1. Muy práctico,
    ¿Cuánto tiempo máximo permanece abierta una transacción?
    ¿Existe el límite que tenemos de 4 minutos como en v6?
    ¿Se puede establecer un tiempo máximo para transacciones bajo bloqueo duro?. Con el objetivo de que se deshaga de forma automática por superar el tiempo permitido previo aviso al operador.
    Antonio Vela
    http://www.velavisual.com 

  2. Es una opción que va a permitir todavía un mejor control de la plataforma en todo lo referente a cómo nos gustaría llevar el tema transaccional.

    Recomiendo a todos ver el vídeo de Juan ya que en 2 minutos podrás verlo en acción y podrás ver toda su potencia de forma clara (como es habitual en él).

    Un saludo.

  3. Me parece una gran mejora que aumenta el control del programador y la integridad de los datos. Entiendo que el enganche deja de permanecer vivo cuando se corta la conexión por cualquier motivo, entre el vClient y el vServer; y en ese momento el servidor deshace la transación sin esparar ningun tiempo.

Dejar un comentario