>.- En el botón procesar tengo colocado esto para usar el buffering optimista (3):
>=CursorSetProp("Buffering",3,"deudasproveedores")

Bueno, la manera común de usar el buffering es activar el TableUpdate() antes de que el usuario haga el primer cambio.

Si abres las tablas programáticamente, esto lo harás en el evento Form.Load(); inmediatamente después de abrir la tabla, aplicas el buffering.

>He echo una busqueda por todo el formulario y en ninguna parte estoy utilizando el TableUpdate(). ¿Esto podra ser uno de los problemas porque no estoy usando el TableUpdate()?

La idea de usar buffering es, precisamente, para que el usuario pueda confirmar o bien anular cambios. Se confirman los cambios con TableUpdate(), y se anulan con TableRevert().

>>Si el usuario hace click en "Anular" (Deshacer), se ejecuta TableRevert().
>El Tablerevert lo uso en el boton deshacer:
>=Tablerevert(.T.,"deudasproveedores")

Esa parate me parece bien.

>Deseo que sí un usuario esta usando un determinado registro y otro usuario desea hacer uso del mismo al dar click en el boton procesar muestre un mensaje como por ejemplo:
>Messagebox('El registro con la factura número '+lcBloqueaRnc+' está siendo utilizado por otro usuario.',0+16,'ERROR AVISPAO') ; con esto pienso yo que bastaria para que no lo use para nada.

Y bueno, se puede bloquear registros explícitamente con rlock(), o bien usar buffering pesimista.

Sikn embargo, la manera más común de trabajar, hoy en día, es el "buffering optimista"; eso significa que se hace la verificación sólo cuando el usuario intente guardar.

Por una parte, la probabilidad de que dos usuarios realmente trabajen sobre el mismo registro (lo modifiquen) al mismo tiempo, es bastante baja.

Por otra parte, si realmente se diera el caso, la integridad de los datos está protegida - el segundo usuario simplemente no podrá guardar los cambios.

Entiendo que el buffering optimista es la única manera de interactuar en un entorno cliente-servidor. Además, el tráfico optimista reduce el tráfico de red innecesario, y conflictos de uso, también innecesario. Por ejemplo, digamos que un usuario bloquea un registro, pero después ni siquiera lo modifica. Otro usuario no podrá acceder al mismo registro. O bien, un usuario comienza a modificar un registro, pero después decide anularlo. Con el buffering optimista, ni siquiera se bloquea el registro, hasta que se intente guardar.