FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Bloquear registro
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? |
#2
|
||||
|
||||
Cita:
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.
__________________
Miguel Román Afectuoso saludo desde tierras mexicanas....un aguachile?, con unas "cetaseas" bien "muertas"?, VENTE PUES !! |
#3
|
||||
|
||||
¿Haz probado con WITH LOCK?
__________________
Buena caza y buen remar... http://mivaler.blogspot.com |
#4
|
||||
|
||||
Cita:
__________________
Dulce Regalo que Satanas manda para mi..... |
#5
|
|||
|
|||
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. |
#6
|
||||
|
||||
Cita:
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#7
|
|||
|
|||
Cita:
|
#8
|
||||
|
||||
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: Cita:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#9
|
||||
|
||||
Cita:
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]
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. Última edición por Neftali [Germán.Estévez] fecha: 03-12-2020 a las 13:48:14. |
#10
|
|||
|
|||
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? |
#11
|
||||
|
||||
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.
|
#12
|
||||
|
||||
Cita:
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).
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Bloquear un registro.... | Jose Roman | SQL | 2 | 26-10-2010 05:24:18 |
Bloquear un registro. | ppb | MySQL | 0 | 01-03-2009 13:08:18 |
bloquear registro!! | Juan Carlos | MySQL | 1 | 17-12-2005 21:49:31 |
bloquear registro | armando | Tablas planas | 2 | 25-10-2005 16:48:53 |
Bloquear 1 Registro | AGAG4 | Firebird e Interbase | 1 | 14-09-2004 10:53:27 |
|