Otra vez con los índices !!!!

[miarcod]

Hola de nuevo,
Antes de nada agredecer a todos la atención y el apoyo ofrecido.

Bueno, el caso es que tengo un sistema que desde hace unos dias se comporta de un modo extraño. Claves de indice duplicadas e incluso indices que no respetan la clave de ordenación.
El ultimo caso es el de un indice que al activarlo los registros aparecen ordenados hasta un punto determinado y en ese punto hay un registro que no respeta el orden.
Este fichero tiene mas de 200.000 regs. y el campo que produce este comportamiento es un campo del tipo id (caracter,10) que voy incrementando cada vez que se agrega un registro. Activo el orden voy al final y sumo uno al valor del ultimo registro. En un momento determinado se guarda el numero 1 (a pesar del tamaño del fichero) y todos los que se guardan a continuación se guardan con el número dos, es decir. siempres que voy al final del fichero me encuentro el mismo registro.
Si se vuelven a crear los indices se corrige el error, pero claro no es cuestion de estar regenerando indices cada hora.
De momento lo que he implementado es un control para detectar el momento en que se produce esta situación. Y si el valor que obtengo es inferior a la cantidad de registros es que el índice está mal.

El sistema de ficheros es DBF Y CDX

Code: Select all  Expand view  RUN

Area   9 => LINPRESU [......DATOS\LINPRESU.DBF]
Indices: [....DATOS\LINPRESU.CDX] (4 TAGS)
  ==> [LINPRES1] CODPRE FOR !DELETED()[ 224271]
      [LINPRES2] ENLACE FOR !DELETED()[ 224271]
      [LINPRES3] CODCLI+CODART FOR !DELETED()[ 224271]
      [LINPRES4] CODART FOR !DELETED()[ 224270]
Reg. 210511 de 224359
Bloqueos: (0)
Filtro:

El tag en el que se produce el error es LINPRES2
y observo que el último tag LINPRES4 tiene un registro menos que el resto ????

Alguien me podría indicar en que circunstancias se puede producir el error, para intentar localizar el problema

Gracias.

[Garbi]

¿Usas Windows 7?

Si así sigue estos pasos y prueba:

El problema radica en un problema de protocolo SMB entre diferentes versiones de Windows, windows 7 utiliza el protocolo SMB 2.0 y al compartir ficheros
con otras maquinas windows origina ese problema, en realidad es un problema de Microsoft entre sus distintas versiones, creo que la solución
es uniformizar al protocolo SMB 1.0

ejecutar como administrador los siguientes comandos en el servidor

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi

sc config mrxsmb20 start= disabled

[miarcod]

Gracias por responder,

Los ficheros se encuentran en un servidor linux debian, que comparte una carpeta con samba.

[Garbi]

¿Y los puestos que sistema operativo usan?

[Carlos Mora]

Los ficheros se encuentran en un servidor linux debian, que comparte una carpeta con samba.

Podrías postear la configuración del Samba?
Tienes desactivados los oplocks? Los bloqueos en Unix no son compatibles con los de smb/cifs, suelen dar inconvenientes.


Por otro lado, la solucion del gobottom, id+1 no es buena porque dos estaciones en paralelo podrían obtener el mismo ID. En mi caso uso algo parecido a los sequencers de postgress: una tabla que tiene un registro por cada numerador del sistema, y sus respectivas rutinas de gestion de contadores: actual(), siguiente() que cuando voy a incrementar bloqueo el registro, luego incremento, commit/unlock y recien ahi devuelvo el valor. Funciona bien, porque siempre hago un seek lo que garantiza que te traes el ultimo registro.

[hmpaquito]

Hola,

Ideas:

1. Algo ha cambiado en el sistema. Probablemente un equipo nuevo o una actualizacion de Windows.
2. Samba es un "bicho" extraño a Windows. ¿ Quien garantiza compatibilidad "temprana" con nuevas versiones Windows ?
3. Configura el antivirus para que excluya de análisis y protección la carpeta de tu aplicación.
4. Crea unos test con dbfs paralelas que intente simular (automaticamente) la adicion simultanes de registros desde varios puestos. Esto te ayudará a localizar el problema y más tarde a comprobar de que ha desaparecido.

Salu2

[hmpaquito]

Ey D. Carlos,

De cabeza, yo lo hago asi como:

Code: Select all  Expand view  RUN

FUNCTION ContadorAsientos()
Local nAsto
SELECT Contador
GO Recno()
Rec_Lock(0)
   nAsto:= NumAsi+ 1
   REPLACE NumAsi WITH nAsto
   COMMIT
UNLOCK
RETURN nAsto

¿ Que te parece ? ¿ Es mejorable ?

Los ficheros se encuentran en un servidor linux debian, que comparte una carpeta con samba.

Podrías postear la configuración del Samba?
Tienes desactivados los oplocks? Los bloqueos en Unix no son compatibles con los de smb/cifs, suelen dar inconvenientes.


Por otro lado, la solucion del gobottom, id+1 no es buena porque dos estaciones en paralelo podrían obtener el mismo ID. En mi caso uso algo parecido a los sequencers de postgress: una tabla que tiene un registro por cada numerador del sistema, y sus respectivas rutinas de gestion de contadores: actual(), siguiente() que cuando voy a incrementar bloqueo el registro, luego incremento, commit/unlock y recien ahi devuelvo el valor. Funciona bien, porque siempre hago un seek lo que garantiza que te traes el ultimo registro.

[Carlos Mora]

Ey D. Carlos,

De cabeza, yo lo hago asi como:

¿ Que te parece ? ¿ Es mejorable ?

Es ideal. Lo unico que hago distinto es que tengo una sola tabla para todos los contadores, y le hago siempre un seek para segurarme que no me está cacheando el registro.
Si puedes, y como medida adicional para una funcion específica de los numeros de asiento ¿Que tal que una vez que incrementó el contador de asientos lo busque en asientos para asegurarse que el numero no existe y no fue incluído de forma inconsistente con el contador? Aunque seguramente yo lo hubiese separado en dos funciones.

[hmpaquito]

Carlos,

Efectivamente, hago seek a la tabla de asientos, paporsi. Y más de una vez me he encontrado un paporsi. ¿ Motivo ? ¿ Quien sabe ? Con tanta samba, tanto smb, tanto OS distinto, tanto antivirus dando la vara, lo raro es que algo se grabe bien (me viene a la cabeza el acrónimo RDBMS)

Al tema de los asientos le tengo incluido una "recuperacion de huecos de numero", lo cual incrementa el sarao del contador de asientos.

Pero bueno, es una historia vieja que lleva mucho tiempo ruling correctamente.

Salu2

Ey D. Carlos,

De cabeza, yo lo hago asi como:

¿ Que te parece ? ¿ Es mejorable ?

Es ideal. Lo unico que hago distinto es que tengo una sola tabla para todos los contadores, y le hago siempre un seek para segurarme que no me está cacheando el registro.
Si puedes, y como medida adicional para una funcion específica de los numeros de asiento ¿Que tal que una vez que incrementó el contador de asientos lo busque en asientos para asegurarse que el numero no existe y no fue incluído de forma inconsistente con el contador? Aunque seguramente yo lo hubiese separado en dos funciones.

[miarcod]

Yo lo que estoy haciendo ahora es:

Compruebo si puedo abrirr un fichero de semaforo en modo exclusivo (sin o lo creo y lo abro en modo exclusivo) lo cual me garantiza que no hay otro proceso dando de alta otro registro en la misma tabla. Si no puedo crear el semaforo cancelo el alta.
Obtengo un nuevo id (gobottom+1)
Agrego un nuevo registro al fichero y le asigno el nuevo id
Debloqueo del fichero de semaforo
Teoricamente no se deberían poder crear dos registros con el mismo id ¿no?

Si lo que hago es una modificación entiendo que con el bloqueo del registro ya garantizo que los datos se actualizan correctamente, además cuando el usuario intenta modificar una consulta, vuelvo a recargar los datos del registro por si desde otro proceso fueron modificados y no se corresponden con los visualizados en la pantalla

[hmpaquito]

Teoricamente no se deberían poder crear dos registros con el mismo id ¿no?

Le veo inconvenientes, pero no por repeticion del numero sino por devolver erroneamente el contador a uno y es por lo que sigue:

Si hubiera dos o mas procesos interviniendo en la tabla, y en uno de ellos se hiciera un alta masiva de registros.
En el momento de hacer el ADD_REC(), hay unos milisegundos, antes del REPLACE, que el valor del campo es vacio o cero, y si el otro proceso está con el GO BOTTOM, al sumarle uno devolveria uno como contador.

Es decir, el problema lo veo en un alta masiva de registros con el mismo contador todos (caso de varios apuntes del mismo asiento) o tambien con distinto contador.

Habria que hacer tests intensivos simulando multiple acceso.

A ver si Carlos nos puede alumbrar con su seguro saber.


EDITADO
=======

Una posible forma de evitar el (posible) problema planteado seria bloqueando el registro, antes de tomar el valor. Seria asi

SELECT Diario
GO BOTTOM
Rec_Lock(0)
nContador:= NumAsi+ 1
UNLOCK