Linha Microsiga Protheus - Espanhol

Atalhos

Árvore de páginas

Intento de reservar registro en el Alias X en EOF Stack de llamadas en MSRLOCK.eof Control de transacciones Habilitado

Producto:

Microsiga Protheus®

Ocurrencia:

Mensaje: Intento de reservar registro en el Alias X en EOF Stack de llamadas en MSRLOCK.eof Control de transacciones Habilitado

¿Intenta nuevamente? Este mensaje finalizará en 5 segundos

Concepto:

El control de transacción es una herramienta importante que garantiza la integridad de datos cuando una determinada operación se realiza en la Base de datos.

El Protheus tiene el parámetro MV_TTS que cuando se activa garantiza que este proceso exista en los procesos críticos de transacción de archivos.

Las alternativas existentes en la actualización de tablas son:

  • Hacer efectiva la transacción - cuando se realiza con éxito
  • Volver al estatus anterior (rollback) - revierte toda la transacción iniciada cuando el final de la transacción no se finalizó con éxito. Esto garantiza la total integridad de los datos.


El mensaje "EOF Stack en MSRLOCK" indica que la rutina intentó reservar un registro para manejarse en el procesamiento; pero el puntero de la tabla estaba en FINAL DE ARCHIVO (MODO EOF) pues no encontró el dato buscado en la Tabla.
Es decir, algún dato (relacionado a este registro que se está procesando) no está válido / no se encontró, presentando quiebra de integridad.

Se graba un archivo de log denominado msrlock.eof en la carpeta system. Para una correcta verificación, debe realizarse el proceso con la ocurrencia en entorno de homologación donde ocurra el problema, después de borrar este registro (para eliminar datos grabados anteriormente).


EJEMPLO

Supongamos que el mensaje ocurre al intentar generar / borrar un Doc. de Salida.


Entonces algún dato relacionado con este Doc de Salida no está válido / no se encontró, presentando quiebra de integridad.

Por ejemplo, puede ser algo no válido en el registro del TES utilizado en el Pedido de ventas; puede ser que en el código del Cliente / Proveedor / Tienda esté registrado un código no válido, que no existe; puede contener un código de Producto en el grid, o un código de condición de Pago, o el código del Ítem, u otro dato cualquiera el cual no existe/ no es válido, etc.

Procedimientos:

OBSERVACIÓN

Si el entorno estuviera almacenado en el Cloud Data Center da TOTVS, será necesario activar puntualmente el Soporte Cloud mencionando los ítems específicos que necesitan de intervención del Cloud, para que suministren los datos mencionados para análisis.

    Es necesario rastrear específicamente en el entorno para identificar qué registro de la base está con el problema.
    De esta manera, el primer análisis es evaluar si los registros que está intentando procesar tienen datos válidos en la Base, principalmente para la Tabla apuntada en el alerta y las vinculadas al proceso ejecutado.

    Se recomienda realizar simulaciones para aislar el problema / el registro.
    Ejemplo, incluir un registro idéntico en la base de datos y verificar si el registro se graba en las tablas con los mismos datos y si el problema también ocurre.

    Este tipo de información incorrecta puede haberse incluido o por manejo de datos en la Base (procedimiento no indicado) o por la propia rutina sin haber ocurrido la validación adecuada (posiblemente debido a una de las causas mencionadas a continuación).


    • Personalización por punto de entrada:
      Algunas personalizaciones utilizan los comandos dbSeek, MsSeek, dbGoTo, etc. que desubican los registros de tablas utilizadas en las rutinas del producto estándar, causando el problema de "EOF Stack en MSRLock". En este caso recomendamos que utilice un RPO limpio sin personalizaciones para verificar si el problema está siendo provocado por alguna personalización.

      Si no fuera posible utilizar un repositorio limpio para la prueba, es necesario habilitar en su entorno la clave IXBLOG=NORUN (Para más información, acceda a: http://www.tdn.totvs.com.br/display/public/mp/Chave+IXBLOG)

      Registre la línea de comando IXBLOG=NORUN en el ini del server, dentro de la sesión del entorno.

      ¡Simule el proceso y verifique si permanece la inconsistencia!

      Después de la ejecución del procedimiento la línea creada en el *.INI del server debe retirarse, pues puede causar bajo desempeño en el sistema si se mantiene.

      OBS: Si aún permaneciera, se graba un archivo de log denominado msrlock.eof en la carpeta system.
      Para la correcta verificación, debe realizarse el proceso con la ocurrencia en entorno de homologación donde ocurra el problema, después borre el archivo grabado en el directorio (para eliminar datos grabados anteriormente      ).



    • Personalización por diccionario de datos:
      Verifique si existen personalizaciones en la estructura del Protheus, como por ejemplo, Índices (SIX) o disparadores (SX7).

      Realice una copia de seguridad de los archivos en la Carpeta System y cree nuevamente con un diccionario de datos estándar como actualizado. Rehaga el proceso.
    • Asegúrese de estar con las últimas actualizaciones del Portal del Cliente. En un entorno de homologación, pruebe con el último RPO, Binarios, DBACCESS, LIB y el paquete quincenal de actualizaciones. Verifique si en este escenario ocurre el problema.


    AVISO IMPORTANTE

    Existen procedimientos incisivos para el sistema en algunos de los procesos mencionados, que deben ser realizados por su Equipo de TI, aconsejamos que si tuviera alguna duda en el proceso, solicite el seguimiento de un consultor Totvs.

    Los procedimientos indicados se utilizan para rastrear la posible causa de la ocurrencia.

    Si aún ocurriera a pesar de la debida realización de los procedimientos, es necesario solicitar ayuda del equipo de Soporte investigativo TOTVS para que acceda remotamente a su base, con el objetivo de evaluar/ depurar la rutina para analizarla e identificar el origen del problema.