SoloCodigo

Pues añade un byte que indique si ese registro está siendo usado (byte = 1, usado, = 0 libre). Cuidado con la concurrencia, es decir, es posible que 2 vendedores accedan exactamente a la vez al campo y vean que está a 0 los dos. Aunque la probabilidad de que ello ocurra teniendo tan sólo 5 accesos simultáneos, la Ley de Murphy siempre está ahí. Un saludo.

   m0skit0 escribió:Pues añade un byte que indique si ese registro está siendo usado (byte = 1, usado, = 0 libre). Cuidado con la concurrencia, es decir, es posible que 2 vendedores accedan exactamente a la vez al campo y vean que está a 0 los dos...

 

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

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.

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

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.