Programación General > Visual Basic 6.0 e inferiores
Bloqueo de Registros
m0skit0:
--- Cita de: "xZerox" ---que pasa si un usuario del sistema ingresa y bloquea el registro (poniendole el estado a 1), pero justo en ese momento se reinicia la PC, el registro se va a quedar bloqueado y nadie podra acceder ya que sigue estando bloqueado
--- Fin de la cita ---
Efectivamente, tienes razón, pero ese problema que mencionas en inherente a cualquier sistema concurrente. ¿Qué pasa en un SO cuando un proceso bloquea un recurso y luego se cuelga? Exactamente lo mismo. Es un problema harto complicado de solucionar, aunque se me ocurre que podrías ponerle un time-out al bloqueo, es decir, que pasado cierto tiempo el registro quede de nuevo habilitado para el acceso. Un saludo y suerte.
9tnix:
Hola xZerox
A mi se me ocurre un artificio usando sockets, pero la solucion deberia estar como dice F_Tanori en el DBMS, pero se ocurre lo siguiente:
Creas 2 aplicaciones 1 cliente en cada estacion y 1 en el servidor de tal forma que esten conectados permanentemente. el proposito de estar conectados es que cuando 2 o + usuarios accedan al registro al mismo tiempo pues el programa servidor determine quien es el primero que accedio y en una tabla (que esta en el servidor) guarde la siguiente info temporal: IDEquipo, Tabla, IDRegistro, Estado=1 asi cuando el resto quiera acceder pues no podra porque primero para accede a un registro tendra que leer en esta tabla y ver si el registro al que quiere acceder esta o no bloqueado.
Ahora que pasa si se apaga la pc del usuario entonces lo que sucedera es que se perdera la conexion entre los programas cliente y servidor por lo que si sucede eso pues se debe borrar de la tabla (que esta en el servidor) el registro que bloqueo esa maquina que se apago y volvera a estar disponible para el resto de usuarios.
Bueno eso es lo que se me ocurre como artificio, algo laborioso pero es una idea.
Saludos cordiales
Att. Zeekel
Nebire:
--- Cita de: "xZerox" ---Bueno ante todo gracias por la debida atencion
Pero = el cliente perderia tiempo esperando a que en cualquiera de los puntos le digan que justo en ese momento ya se acabo de vender el producto a otra persona.... esto es lo que me preocupa mas que todo
--- Fin de la cita ---
Esto suele arreglarse con mayor o menor comodidad creando un trigger ( create trigger ), debes indicar el límite cuando el trigger entrará en funcionamiento, por ejemplo si hay 10.000 artículos en stock de un producto está demás, pero si quedan 20 en las 4 tiendas de una ciudad, (por ejemplo) sería bastante útil.
El trigger lo que debería hacer es que una vez que de un producto (o de una lista de productos) queden menos de x cantidades (al caso tener una tabla especificando qué producto y cual es su límite mínimo) en una tabla (tbl_StockMin) añadir (serían los campos de la tabla) el nombre del producto los artículos que restan, los que están reservados, el período de reserva ( por ejemplo 40 minutos) y hora de reserva ... ahora cuando un cliente pregunte por un producto y demuestre ese interés el 'vendedor' hace la reserva, el trigger se dispara automáticamente (a través de un procedimiento almacenado que en cada llamada consulta y luego compara el stock del artículo con la tabla tbl_StockMin articulo=el_preguntado y valor <= tbl_Stockmin.min, si se da el caso el trigger comprueba si el artículo consta en la tabla, si no consta lo añade, fija la hora de reserva, y previamente si hubiera una reserva sobre ese artículo comprueba si la hora de reserva + el tiempo máximo de reserva es mayor que la hora actual, si es que sí, ese artículo libera una unidad de reserva (si las unidades en reserva llegan a cero el artículo se retira de la tabla) , existe por tanto la posibilidad de decirle al cliente que hay una reserva que caducará en x minutos, que si lo desea se pase después de ese tiempo porque o se ha vendido o se ha retirado la reserva. Por supuesto cuando se vende definitivamente esa reserva se retira de la tabla tbl_stockmin y además decrece el stock en una unidad, si las unidades alcanzan definitivamente cero se retira de la tabla y la referencia se pasa a la tabla de artículos agotados para peticiones al almacén o lo que se quiera...)..
Si se cuelga el ordenador, no pasa nada ya que la próxima petición a ese producto actualiza automáticamente el estado actual del producto y de las reservas.
No es necesario programar otro trigger para comprobar la vigencia de una reserva sino que se actualiza justo cuando surja otra petición y compruebe que el stock.
Ten en cuenta que utilizar triggers sin ton ni son hace trabajar muy pesado a una base de datos, por tanto úsalos con cautela...
Hablamos de 2 tablas: Una retiene que artículos serán 'vigilados' y a partir de que límite de stock un trigger controla las reservas de ventas y el tiempo máximo de reserva para dicho artículo (por ejemplo un TV puede reservarse 60 minutos, pero una moto 4días y una vivienda 1mes, según el valor el período puede variar e incluso para los de gran valor sólo se admite reserva previo pago anticipado de una cuantía, en dicho caso esa tabla también debería tener ese campo . La otra tabla, la 2ª de la que hablo, mantiene los datos de reserva, producto, stock actual disponible, reservas hora de reserva hora de final de reserva y adicionalmente algún dato del cliente que lo reserva. La primera tabla puede o no crearse o añadir esos campos a las tablas de artículos, lo cual irá en función de que sería más rentable en función de la cantidad de artículos del alamcén, la cantidad de stock de cada artículo, la cantidad de clientes y ventas-reservas, etc... si tienes 10000 artículos pero son 20 los artículos que se venden como rosquillas quizás interese una tabla y sólo sobrecargar cada consulta con una comprobación de procedimiento alamacenado cuando sean alguno de esos 20 artículos los solicitados por el cliente, en los otros 9980 no.
[Zerox]:
bueno nebire, me parece buena tu idea, igualmente la de zeekel
Vere cual de las 2 implementare, claro que tomando en cuenta que no se realizan reservas de productos o articulos, ya que no es una regla de negocio de la empresa el separar articulos, pero vale nebire muy interesantes aportes, los tendre en cuenta gracias igualmente a ambos...
Navegación
[*] Página Anterior
Ir a la versión completa