Linha Microsiga Protheus - Espanhol

Atalhos

Árvore de páginas

Versões comparadas

Versão antiga 1

changes.mady.by.user Rafael Fernando Villanueva Alegre

Gravado em

comparado com

Nova versão 2

changes.mady.by.user Rafael Fernando Villanueva Alegre

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

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

Image Added

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. Detalles: Control de transacción - MV_TTS

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:

Observação: Caso o ambiente esteja armazenado no Cloud Data Center da TOTVS, será necessário acionar pontualmente o Suporte Cloud mencionando os itens específicos que necessitam de intervenção do Cloud, para que forneçam os dados mencionados para análise.


1º Rastreo del dato incorrecto vinculado al registro

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).


2º Personalizaciones / Personalizables en su entorno.

      • 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.

        (ideia) 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)
        Registrar 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 borrar el archivo grabado en el directorio (para eliminar datos grabados anteriormente        ).


      • Personalización por Diccionario de datos:
        (ideia)Verificar si existen personalizaciones en la Estructura del Protheus, como por ejemplo, Índices (SIX) o disparadores (SX7).
        Realizar una copia de seguridad de los archivos en la Carpeta System y crear nuevamente con un diccionario de datos estándar como actualizado. Rehacer el proceso.


3º Inconsistencia en la rutina posiblemente causada por actualizaciones incompatibles en el entorno

Certificarse de estar con las últimas actualizaciones del Portal del cliente. En entorno de homologación probar con el último RPO, Binarios, DBACCESS, LIB y paquete quincenal de actualizaciones. Verificar si en este escenario ocurre el problema.


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.