El mecanismo que instrumente no dependia del usuario.
El sistema, cada vez que habría una tabla "contaba" en un archivo de control (por ejemplo un tipo .mem que se guarda variables de memoria.). Sumar 1 a un contador por archivo o tabla abierto.
Ese archivo de control se accedía exclusivo, se actualizaba (conteo de "abiertos") y se cerraba (operación casi instantánea), luego cuando se cerraba la tabla, el sistema actualizaba el archivo de control, descontando.
Cuando se producia una caida de la red (corte de luz) o algún problema planche del sistema. El archivo de control quedaba con "contadores" de archivos abiertos en positivo.
Al arrancar el equipo donde están las tablas dbc. Se dispara un programa que chequea si hay "contadores positivos" por archivos abiertos chequeando en el archivo de control. Si es así, automaticamente, pone todos los archivos que figuraban con contadores distintos de cero con -1.
Luego cuando la/s aplicacione/s accedian a una tabla y en el archivo de control encontraban la marca -1, intentan obtener el uso exclusivo del archivo, si lo logran, cambian la marca a -2, y hacen reindex de sobre esa tabla, avisando al usuario que está reorganizando la bd, al terminar de reindexar, cierra y pone el contador (en control) en cero; si no puede obtener uso exclusivo, mandan un mensaje al usuario que no puede trabajar, por tareas administrativas. Si encuentra la marca -2, directamente avisa que no puede usar el sistema por razones administrativas.
Cuando un usuario recibe un mensaje de que el sistema esta en administrativo, puede dispararse un timer, para que para los casos de contador -2, pueda haber quedado el contador en 0 o más.
Con ese mecanismo (aclaro que ya con fox p/dos, tenía centralizado la apertura y cierre de tablas) era muy dificil que una tabla quedara con indices rotos. Por un mal cierre.
Igual mecanismo se puede utilizar para controlar o retrotraer transacciones con problemas.
En mi caso, para el tema de transacciones, que Fox2 no contaba, usaba lógica de estado. Toda tabla contaba con un campo (un caracter) que al empezar la transacción, se ponía por ejemplo en 0, cuando terminaba la transacción, pasaba el estado a 1 y así, si había una caida en el medio. El programa, al arrancar y detectar que debía reindexar, además chequeaba todos aquellos registros que tenían una marca de "en proceso" y deshacia operaciones, o avisaba al operador que debía corregir a mano el proceso interrumpido (a veces no era facil instrumentar un rollback, y el operador, podía eliminar las incompletas y reprocesarlas.
En fin, por suerte aparecieron las SGBD con transacciones y demás sin tener que codificarlo.