El problema de acumular datos!!!

Lo ideal seria con el manejo de transacciones, pero creo que las bases dbf
no soportan transacciones :(

Ojala y este link pueda ayudarte
http://www.15seconds.com/issue/030604.htm

Saludos!
http://www.neo-mx.com/blog




"dgironal" wrote in message
news:%

He de manejar una base de datos diseñada por terceros (Factura Plus)
realizada en FoxPro (dbf / CDX) y me encuentro con el siguiente problema:



He de actualizar la siguiente tabla que acumuma el stock (yo no lo he
heho...)

TablaStock

Almacén Artículo Stock .





Bien, a grandes rasgos lo que tengo que hacer es:

1;- Vendo artículos

2;- Actualizo el stock



Con un solo usuario no hay problema:

1:- Leo el stock (quedan 67)

2;- Yo vendo 20

3;- Actualizo el stock a 47 (67-20) (lo que había-lo que vendo)



El problemón viene cuando hay varios usuarios (condiciones de carrera)



Usuario1 lee stock 67

Usuario1 vende 20

Usuario2 lee stock 67 <- MAL!!!

Usuario1 actualiza el stock 47 (67-20) (lo que había-lo que vendo) <-

MAL!!!

Usuario2 vende 25

Usuario2 actualiza 42 (67-205) (lo que había-lo que vendo) <-MAL!!!



No tiene ni pies ni cabeza



¿Cómo se arregla esto, bloqueos, transacciones?

Utilizo VB.NET/ADO .NET

Con ADO classic podrías hacerlo (creo) utilizando bloqueos. La forma de
forzar un bloqueo con ADO es usar recordsets de servidor, de conjunto de
claves con bloqueo pesimista. Mientras un recordset de este tipo está
posicionado en un registro no puede haber otro recordset del mismo tipo
posicionado en el mismo registro al mismo tiempo porque está bloqueado. Así
que si todas las aplicaciones acceden de esta manera no habrá problema, pero
si hay una que lee los datos con bloqueo optimista, la hemos fastidiado.

Usando ADO.NET podrías solucionar el problema evitando actualizar las
existencias basándote en un valor leído anteriormente, sino en el valor que
tiene actualmente. O sea en vez de:

1:- Leo el stock (quedan 67)
2;- Yo vendo 20
3;- Actualizo el stock a 47 (67-20) (lo que había-lo que vendo)

Hago lo siguiente:

1.- Leo el stock (quedan 67)
2.- Yo vendo 20
3.- Actualizo el stock: UPDATE TablaDeSTOCK SET STOCK = STOCK - 20 WHERE
CodArticulo = ElCódigo
4 .- Leo el stock A lo mejor no son 47 porque alguien ha vendido algo
antes: entre justo después del paso 1 y justo antes del paso 4

Así no hay incosistencias, o por lo menos eso creo, aunque con los dbf's no
estoy seguro del todo, ya sabes ... lo mío es el SQL Server.

Saludos:

Jesús López
MVP

Mi opinión es que tienes un problema de protocolo:

Si lees es stock para saber si puedes vender 20 artículos, el protocolo que
propones es leer stock, y comprobado que es mayor que 20 modificar stock.
Este protocolo provoca el problema de concurrencia que comentas. Por esto
te propongo este protocolo:

Quiero vender articulos: Realizo de una sola vez la comprobación de
existencias y la venta:

UPDATE TablaStock SET Stock=Stock-20 WHERE (IdArticulo=TuArticuloVendido AND
Stock>20)

y devolver un valor que indique si la operación se ha realizado o no.

Mil gracias, los tres comentarios me han hecho ver otro punto de vista,
vuestras propuestas me han sido muy útiles, lo voy a implementar, ya os
contaré.