FoxPro/Visual FoxPro - Ayuda porfa?????

Hola miren he estudiado sobre actualizar el buffer, pero aún tengo una pregunta que pasa si en un formulario hay alguien que actualiza una tabla completa Buffer,5 y esta en este proceso, y en otra parte hay alguien que actuliza solo un campo de la tabla, buffer,4.

No he comprendido lo de SET REPROCESS quien me puede dar una explicación clara sobre que peligros o que debo hacer, y lo del Set reprocess, gracias.

Yo hago el bloque así: EN el formulario pongo BufferMode=2,

SELECT <Tabla>
IF RLOCK()
SET MULTILOCKS ON
=CURSORSETPROP('Buffering',5,'Tabla')
=TABLEUPDATE(.T.)
UNLOCK
ELSE
Mensaje "No se puede porque otro usuario esta en la tabla"
ENDIF

En este enlace, debes elegir a Jim Booth y a Doug Hennig. Ellos tienen artículos sobre Buffering
http://www.portalfox.com/modules.php?op=modload&name=Sections&file=index

El cursorsetprop se debe ejecutar en el LOAD de la forma, ya que si lo pones como tu lo haces no estas haciendo nada. Cuando usas buffer significa que trabajas con dos tablas la real y una extra (creada por el fox). En la extra se van guardando tus cambios y cuando ejecutas el tableupdate estos datos se pasan a la tabla real.
En realidad,no ocupas el RLOCk en este caso ya que el tableupdate se encarga de ellos automaticamente (si podrias usar el RLOCk pero te puede traer problemas). En tu caso lo que haria es algo como esto:

set reproces to 5
begin transaction
If !tableupdate(1)
=messagebox("error",32,"mesnaje")
rollback
else
=messagebox("Se grabo",32,"mesnaje")
end transaction
endif

El set reprocess lo que hace es que intenta hacer el bloqueo por un tiempo (segun lo especifiques). Si en ese tiempo no se pudo, el codigo se continua ejecutando.... entonces en el codigo que te di si no se puede bloquear entonces
el tableupdate se corre pero como no puede salvar todos los cambios entonces no se guarda nada, asi que el usuario tendria que correr otra vez el codigo.
Las transacciones (begin transaction, rollback, end transaction) te ayudan a asegurarte de que se graban todos los cambios, si no se puede grabar uno no se graba nada. Lee que los articulos que te ofrece Manuel asi podras tener mas detalles del asunto.

Gracias, pero entonces es más seguro usar Transacciones?
Otra cosa si lo que quiero es que no se salven los cambios cambio TABLEUPDATE por TABLEREVERT? y no hay problemas que sean también vistas locales?
Gracias por la ayuda y si me puedes responder esto....

Ok, vamos a ver si te sirve este ejemplo: supongamos que tienes los detalles de una factura (los productos que se compraron) y los queres guardar, pero resulta que a uno de los prodcutos se le borro el nombre (la descripcion). AL momento de guardar la informacion se te van a guardar todos los productos (no siempre se graban todos) excepto el que no tiene nombre (tienes una regla de validacion que impide que esos campos sean vacios). En ese caso los detalles no te sirven porque los datos de la factura no van a corresponder con los datos que guardaste en la tabla, la informacion esta incompleta. Es aqui donde entran las transacciones, ya que al fallar el tableupdate el rollback hace que todos los datos que fueron guardados vuelvan a su estado original (estado del buffer), asi no se guardara nada hasta que toda la informacion sea valida. En conclusion, cuando ejecutas un tableupdate algunos datos se guardan y otros no (en este caso fallo la funcion), para que este no pase se usan las transacciones. El tablerevert te sirve para recuperar los valores orginales de la tabla, es decir, digamos que en un campo cuyo valor orignal es "roberto" y lo cambias por "beto" con el tablerevert podrias hacer que apareciera "roberto" de nuevo (es parecido a un UNDO). Ojo, esto solo funciona con tablas que usan buffers...No es tan necesario el tablerevert()