Desplazamiento de Busqueda No valido.
jkiernan
HERNAN D. A.
P
Crédito CHAT GPT, por ahí te sirve
Problema clásico al ejecutar aplicaciones Visual FoxPro (VFP 9) que acceden a tablas DBF ubicadas en un servidor Windows moderno (2022/2025), sin soporte para SMBv1.
Vamos a desglosar por qué ocurre el error “Desplazamiento de búsqueda no válido”, por qué el ON ERROR no lo captura, y cómo solucionarlo sin reescribir todo el sistema.
💥 1. Causa técnica del error “Desplazamiento de búsqueda no válido”
Este error proviene del motor de archivos DBF de VFP, no del código del sistema.
En concreto, aparece cuando:
-
VFP intenta leer o escribir en un bloque del archivo DBF o FPT (memo) que el sistema operativo no devuelve correctamente,
-
por una interrupción temporal o inconsistencia en el protocolo de red (SMB), especialmente en operaciones de locking (bloqueo de registros) o buffer de escritura.
Esto pasa aunque el archivo esté en red local si el protocolo SMB no se comporta exactamente como VFP espera (algo que cambió mucho después de Windows Server 2016).
⚙️ 2. Qué cambió entre Windows Server 2016 y 2022/2025
SMBv1 vs SMBv2/v3
Visual FoxPro (y todos los motores DBF antiguos) fueron diseñados con SMBv1 en mente (lanman, circa Windows 2000/XP).
Cuando SMBv1 se elimina:
-
Se pierden ciertas operaciones byte-range locking heredadas.
-
Se cambian los tamaños de buffer de lectura/escritura.
-
El servidor puede reordenar o agrupar operaciones que antes eran síncronas.
El resultado:
VFP intenta “buscar” una posición en un archivo DBF o FPT (por ejemplo, SEEK, APPEND, UPDATE, PACK, INDEX, etc.), y el sistema devuelve una posición de archivo no válida → “Desplazamiento de búsqueda no válido”.
💡 Este error es crítico a nivel de motor → se lanza antes de que VFP llegue al ON ERROR. Por eso no se puede capturar ni manejar, y el sistema directamente finaliza la ejecución.
🧩 3. Pruebas que confirman el origen
Podés comprobar que el problema no es del código, sino del protocolo de red:
| Prueba | Resultado esperado |
|---|---|
| Copiar las tablas a una carpeta local (C:\Datos...) y ejecutar el sistema | No se cae más |
| Volver a compartir desde un servidor con SMBv1 activo (Win2016 o Win10 viejo) | No se cae más |
| Mover el servidor a Win2022 pero habilitar Client/Server SMBv1 (aunque esté obsoleto) | Tampoco se cae |
| Mantener SMBv2/v3 y ejecutar en red | Vuelve a caer aleatoriamente |
🧠 4. Soluciones posibles (de menor a mayor robustez)
✅ Opción A — Mantener SMBv1 sólo para ese recurso compartido (rápido, pero legado)
Si la política de seguridad lo permite, podés habilitar SMBv1 sólo para ese recurso compartido o máquina.
Desde PowerShell (en el servidor):
Enable-WindowsOptionalFeature -Online -FeatureName "SMB1Protocol" -All Set-SmbServerConfiguration -EnableSMB1Protocol $true
⚠️ Desventaja: Microsoft considera SMBv1 inseguro (vulnerable a ransomware tipo WannaCry). Solo recomendable en red interna cerrada.
✅ Opción B — Migrar tablas DBF a un servidor local o SQL
-
Mantener la aplicación en VFP, pero hacer que las DBF estén locales (copiadas al equipo cliente), con replicación o sincronización.
-
O migrar los datos a SQL Server / MariaDB / PostgreSQL, usando VFP como front-end.
Esto elimina los problemas de locking SMB, pero requiere ajustes en consultas yRLOCK().
✅ Opción C — Ajustar caché y “file buffering”
Algunos usuarios reportaron reducción significativa de errores al cambiar la configuración de SMB y VFP:
En el servidor:
Set-SmbServerConfiguration -EnableLeasing $false Set-SmbServerConfiguration -EnableOplocks $false Set-SmbServerConfiguration -EnableCachingOfOpenFiles $false
En cada cliente (registro de Windows):
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters] "UseOpportunisticLocking"=dword:00000000 "CscEnabled"=dword:00000000
Y en VFP:
SET SAFETY OFF SET REPROCESS TO -1 SET REFRESH TO 5, 1
Esto no soluciona el problema al 100 %, pero reduce mucho la frecuencia de caída (en muchos casos, desaparece).
✅ Opción D — Montar el recurso vía WebDAV o iSCSI
Alternativamente, si el servidor 2022 no puede usar SMBv1, se puede montar el directorio compartido usando WebDAV o iSCSI local (Windows lo ve como un disco físico).
Así, VFP lo trata como disco local, y no usa SMB.
➡️ Esto elimina los errores de desplazamiento, incluso con SMBv2/v3.
📌 5. Recomendación práctica
| Prioridad | Solución sugerida | Comentario |
|---|---|---|
| 1️⃣ (rápido) | Desactivar leasing/oplocks y caching (Opción C) | Alta compatibilidad, sin bajar seguridad |
| 2️⃣ (seguro) | Montar WebDAV/iSCSI (Opción D) | Permite mantener Win Server 2022 sin SMBv1 |
| 3️⃣ (temporal) | Activar SMBv1 solo para esa carpeta (Opción A) | Funciona al instante, pero no recomendable |
| 4️⃣ (definitivo) | Migrar a SQL Server o similar (Opción B) | Solución estructural y moderna |
--
Blog de la Comunidad Visual FoxPro en Español http://comunidadvfp.blogspot.com
---
Has recibido este mensaje porque estás suscrito al grupo "Comunidad de Visual Foxpro en Español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a publicesvfoxp...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/publicesvfoxpro/eb3ab935-ec38-4ca4-bca8-f311bd07d6acn%40googlegroups.com.
jkiernan
Sergio Rojas
No es necesario bajar a SMBv1, con desactivar los oplocks en el servidor de archivos es suficiente.
Utilizar un servidor en Linux es la mejor opción cuando se tienen más de cinco clientes simultáneos.
Saludos
Sergio
Para ver este debate, visita https://groups.google.com/d/msgid/publicesvfoxpro/69283302-1176-48ad-89cd-fe586897303dn%40googlegroups.com.