El registro de escritura anticipada

Qué cambia

La última fila conviene decirla claro para no crear expectativas: el registro anticipado permite muchos lectores y un escritor, no varios escritores. Sigue habiendo un solo escritor cada vez, y por eso el patrón de una conexión con cerrojo del nivel 41.2 sigue siendo correcto.

Cómo se consolida

Los cambios se acumulan en el fichero de registro y, cada cierto tiempo, se vuelcan al principal. Eso ocurre solo, y hay tres cosas que saber:

• El volcado automático se dispara por tamaño. Cuando el registro pasa de cierto umbral, la siguiente escritura lo vuelca.
• Un volcado no puede completarse si hay lectores antiguos activos, lo que en la práctica significa: si tu aplicación deja una consulta abierta mucho tiempo, el registro crece.
• Y al cerrar la conexión limpiamente, se vuelca todo y los ficheros auxiliares desaparecen. Por eso conviene cerrar bien, y por eso encontrarse los ficheros auxiliares al arrancar es señal de un cierre inesperado — que es la marca útil que el nivel 41.5 sugería para decidir cuándo comprobar la integridad.

El fichero que crece

El problema práctico más común con este modo:

Los dos casos donde no conviene

Y son concretos:

Uno: la base en un disco de red. El registro anticipado usa memoria compartida entre procesos, y eso no funciona de forma fiable sobre sistemas de ficheros de red. Si tu aplicación puede acabar con su base en una carpeta compartida —lo que ocurre en empresas con perfiles en red, nivel 36.5— hay riesgo de corrupción. La respuesta correcta no es cambiar de modo: es que la base no esté ahí, en el directorio de datos local del nivel 39.1, que en Windows es precisamente la parte del perfil que no viaja.

Dos: bases de solo lectura distribuidas contigo. Si empaquetas una base como recurso —un catálogo, un diccionario— y solo se lee, el modo clásico es más simple: sin ficheros auxiliares, sin escritura, y funciona aunque el directorio no sea escribible.