/fox pro en dos monousuario -> red

Es lo que hay valor, eso me tocó en el trabajo. No estoy acostumbrada a trabajar con tablas .dbf, estoy acostumbrada a manejar la concurrencia mediante transacciones. Pero a lo hecho pecho.

Primera estrategia, usar una tabla 'candando', que se llama 'candado.dbf', su única misión es actuar de semáforo para gestionar los accesos concurrentes las tablas. No se bloquean las tablas a acceder, sino el 'candado'.
Ventajas: no atosigar tanto las otras tablas, dar velocidad de consulta.
Desventajas: puede hacerse por fuera de la aplicación, pero las probabilidades que suceda son bajas.

Importante, poner SET EXCLUSIVE OFF en el config.fp o en un archivo del proyecto.
Estos fueron los mayores cambios:
1.- Ruta de Archivos (Prg Bases de Datos y tablas)
--- Set Default to
--- Set Path to
2.- Quitar la Exclusividad de la Base de Datos
--- Set Exclusive Off

PROCEDURE CANDADO_ON
    UNLOCK ALL                &&    Por seguridad
    IF  !USED("CANDADO")
        USE CANDADO IN 0
    ENDIF

    PRIVATE XSR
    XSR=SET("REPROCESS")
    SET REPROCESS TO 1
    DO WHILE !FLOCK("CANDADO")
        DO CINFORME WITH "Los archivos est n en uso...\n\n"+;
            "Toque ENTER para reintentar ya, o espere a que esta "+;
            "ventana se vaya y reintente sola.",2
    ENDDO
    SET REPROCESS TO (XSR)


PROCEDURE CANDADO_OFF
    UNLOCK ALL

Uso:
=candado_on() && en realidad bloque la tabla 'candado.dbf'
insert/append
= candado_off()

No puede usarse con el comando ZAP (vaciar tabla) ya que exige abrir la misma en modo exclusivo, y la tabla queda para ser accedida en forma exclusiva y no pueda compartirse, aun cuando SET EXLUSIVE = OFF. Por lo tanto no libera al usuario de ese recurso, y si algun usuario intenta acceder a la tabla 'zapeada', sale el siguiente mensaje: "File access denied"

Generalmente estas tablas eran usadas para información de reportes, por lo cual opté por crear tablas locales a cada terminal para ahorrarme este problema.
Estas tablas se cargan mediante el resultado de una sentencia SQL (hay un borrado implícito: el resultado de la consula, evitamos usar ZAP).

Hasta la versión 7 de FoxPro no salieron los cursores READWRITE los cuales me hubieran evitado usar tablas, que no son temporales, pero sí locales.
En teoría para FoxPro 2.5 DOS los cursores pueden escribirse/borrarse/indexarse, de hecho lo usé, y me anduvo en modo monousuario pero no se porqué tuve problemas al hacerlo en concurrencia. Concretamente al indexar, mensaje de error: "a read-only file"

No tengo tiempo de investigar el motivo, ni mucho menos me motiva hacerlo en FoxPro, decidí cambiarlo por tablas y se solucionó.

De momento ni siquiera la ORT ha montado la red para probar lo que estoy haciendo, ergo, la forma de testearlo es llamando la aplicación dos veces. Y para probar el ruteo de los archivos (hacia el supuesto servidor) ubiqué los ejecutables en diferentes carpetas.
Los ejecutables son los mismos para cada terminal (servidor y cliente), lo que varía es el archivo de configuración Config.fp en cada máquina.
Al menos algunos problemas de concurrencia han salido a la luz probándolo de esta forma, pero está lejos de lo óptimo como testeo.
Aqui el resultado de la misma aplicación llamada desde diferentes lados: