Bloquear registro

[glopez]

Hola tengo una aplicación de facturación y tengo un problema que cuando estoy editando un albarán no consigo que este quede bloqueado para que nadie pueda editarlo en otro puesto de trabajo o incluso facturarlo.
He probado modificando los parámetros de las transacciones a "no_rec_version" Pero sigue igual.

¿Alguna idea?

[mRoman]

Hola tengo una aplicación de facturación y tengo un problema que cuando estoy editando un albarán no consigo que este quede bloqueado para que nadie pueda editarlo en otro puesto de trabajo o incluso facturarlo.
He probado modificando los parámetros de las transacciones a "no_rec_version" Pero sigue igual.

¿Alguna idea?

Hola amigo gLopez.

Nos ayudaría mucho si nos dieras mas datos, como:
QUE BASE DE DATOS USAS?
QUE COMPONENTES?.

No soy muy experto, pero talvez alguien mas te pudiera apoyar en como solucionarlo...incluso yo, pero con mas información.

Saludos.

[movorack]

¿Haz probado con WITH LOCK (https://firebirdsql.org/refdocs/langrefupd21-notes-withlock.html)?

[oscarac]

Hola tengo una aplicación de facturación y tengo un problema que cuando estoy editando un albarán no consigo que este quede bloqueado para que nadie pueda editarlo en otro puesto de trabajo o incluso facturarlo.
He probado modificando los parámetros de las transacciones a "no_rec_version" Pero sigue igual.

¿Alguna idea?

y que te parece agregar un campo de control, que cuando lo este editando cambie de valor y verificas ese campo cuando alquien mas quiera editar

[glopez]

Hola, utilizo Firebird 3 y los componentes FIBPlus
He probado WITH LOCK, pero de esta forma el registro queda bloqueado nada más que lo leo y lo que necesito es que se el registro se bloquee cuando un usuario comienza a editar y se libere cuando confirme o cancele la edición.

[Neftali [Germán.Estévez]]

Hola tengo una aplicación de facturación y tengo un problema que cuando estoy editando un albarán no consigo que este quede bloqueado para que nadie pueda editarlo en otro puesto de trabajo o incluso facturarlo.
He probado modificando los parámetros de las transacciones a "no_rec_version" Pero sigue igual.



Hay forma de conseguir bloqueos tanto utilizando transacciones como campos de tipo flag en el registro, pero personalmente no lo recomiendo.

En un caso como el de la edición creo que es un error en un entorno multiusuario implementar bloqueos. Piensa siempre en el caso peor. Un usuario edita un registro y mientras lo edita se va a desayunar...

En el caso de facturar, no se cómo lo estás haciedo, pero si es un proceso que requiere intervención del usuario y se puede dar el mismo problema que con la edición, aplicaría lo mismo. Si es un proceso "unitario", puedes hacerlo con transacciones, para que la facturación sea un proceso en el que no existan colisiones.

[glopez]

;539300']Hay forma de conseguir bloqueos tanto utilizando transacciones como campos de tipo flag en el registro, pero personalmente no lo recomiendo.

En un caso como el de la edición creo que es un error en un entorno multiusuario implementar bloqueos. Piensa siempre en el caso peor. Un usuario edita un registro y mientras lo edita se va a desayunar...

En el caso de facturar, no se cómo lo estás haciedo, pero si es un proceso que requiere intervención del usuario y se puede dar el mismo problema que con la edición, aplicaría lo mismo. Si es un proceso "unitario", puedes hacerlo con transacciones, para que la facturación sea un proceso en el que no existan colisiones.

Hola Neftali, comprendo que pueden surgir estas situaciones, ¿que me aconsejas entonces?. Si un albarán está en edición ningún otro usuario debería poder editarlo o facturarlo (cambia el estado PENDIENTE->FACTURADO).

[Casimiro Notevi]

Como dice Neftali, no son necesarios los bloqueos, y más bien son un problema.

¿Cualquier usuario factura cualquier albarán en cualquier momento?
Eso sería una mala organización en la empresa, ¿por qué hay 2 usuarios facturando el mismo albarán?
Pero de todas formas, vamos a suponer que eso sucede y hay que evitarlo, veamos:

User1 abre el albarán A1... y se va al baño y luego a desayunar.
User2 abre el albarán A1
User2 escoge la opción de facturar el albarán A1, el software comprueba que no esté facturado, y lo factura.
User1 vuelve y escoge la opción de facturar el albarán A1, el software comprueba que no esté facturado... y sale un mensaje "Albarán ya facturado".

[Neftali [Germán.Estévez]]

¿que me aconsejas entonces?. Si un albarán está en edición ningún otro usuario debería poder editarlo o facturarlo.

Puedes escoger entre varias opciones, siempre a la hora de grabar. 2 de las más habituales son:

1) Comprobar al grabar si los datos se han modificado.
Usuario1 EDITA Albaran1
Usuario2 EDITA Albaran1
Usuario1 GRABA Albaran1
Usuario2 GRABA Albaran1 ==> Error, Otro usuario ha modificado el registro, vuelve a cargarlo y modifica

2) En ultimo que llega graba.
Usuario1 EDITA Albaran1
Usuario2 EDITA Albaran1
Usuario1 GRABA Albaran1
Usuario2 GRABA Albaran1 ==> Los cambios del Usuario2 sobreescriben los del Usuario1

Puedes utilizar campos de TimeStamp para el caso 1. Se trata de realizar una lectura del registro antes de guardar (para saber si se ha modificado). Algunos componentes de conexión ya hacen esto por ti.

Ahora veo que básicamente es lo que propone [Casimiro]

[glopez]

Hola voy a intentar explicar el caso exacto que me ha pasado a ver que me aconsejáis:

1. User1 Abre el Albarán1, le da a editar, lo deja así y se va a desayunar.
2. User2 decide facturar el Albarán1. Este pasa al estado de FACTURADO.
3. User1 cuando vuelve de desayunar, confirma el Albarán1 que dejó en edición (que estaba PENDIENTE cuando lo abrió) por lo que pasa de nuevo a PENDIENTE.

Podría volver a leer los datos antes de que el User1 confirmara las modificaciones para ver si el albarán ha cambiado, pero creo que lo más correcto sería impedir que facturaran, o modificaran ese albarán mientras alguien lo esté editando aunque esté desayunando. ¿Qué opináis? ¿Creéis que se producirían muchos bloqueos?

[kuan-yiu]

Sí, es una mala política tener que contemplar el caso de que "alguien decida irse a desayunar dejando todo a medias", eso debería formar parte de las normas básicas de trabajo. E incluso acabarías con bloqueos del tipo: se fue la luz/ falló la conexión/ windows explotó/... que tendrías que desbloquear por otros medios.

[Casimiro Notevi]

Es muy simple, por ejemplo, cuando se pulse en el botón "Facturar", haces antes una sencilla comprobación.
btFacturar.Click;
begin
qry.sql.text := 'select facturado from tbAlbaranes where serienumero="A1"';
qry.execute;
if qry.fields[0]='1' then
showmessage('El albarán ya está facturado')
else
Facturar( 'A1' );
end;

procedure Facturar( cAlbaran:string);
begin
...
...
// poner el campo facturado a 1/S/True...
albaran.facturado := 1;
end;

[Neftali [Germán.Estévez]]

Podría volver a leer los datos antes de que el User1 confirmara las modificaciones para ver si el albarán ha cambiado, pero creo que lo más correcto sería impedir que facturaran, o modificaran ese albarán mientras alguien lo esté editando aunque esté desayunando. ¿Qué opináis? ¿Creéis que se producirían muchos bloqueos?

Pues justo yo haría lo primero.
En sistemas concurrentes no tienen sentido los bloqueos de este sentido. Cuanta más concurrencia más problemas vas a tener.
Pero tú tienes la decisión final.

Técnicamente puedes hacer ambos.

El problema de los bloqueos es que tienes que pensar un sistema para liberarlos.
Si el USER1 marca un registro como bloqueado y se le cuelga la máquina o se le cierra el programa, ese registro quedará BLOQUEADO y nadie más podrá modificarlo (por pornerte un ejemplo sencillo).

[glopez]

Al final creo que lo que menos problemas me va a dar, es comprobar a la hora de grabar si los datos han sido modificados.

Muchas gracias a todos por vuestras respuestas.

Un saludo.

[duilioisola]

Yo lo que te recomiendo es que le agregues al albarán una marca de "Facturable".
Cuando el usuario comienza a hacer un albarán, está desmarcado.
Agregará las líneas que sea necesario.
Luego lo marcará como "Facturable".

Cualquiera que quiera facturar solo debería ver los albaranes "Facturables", lo que asegura que el albarán está finalizado.