Histórico da Página

Mensagem: Tentativa de reservar registro no Alias x em EOF Stack de chamadas em MSRLOCK.eof Controle de transaçoes Habilitado

Tenta novamente ? Essa mensagem sera fechada em 5 segundos

O registro encontra-se Bloqueado por outro usuário.

A mensagem referente a "EOF Stack em MSRLOCK" indica que a rotina tentou reservar um registro, mas o ponteiro da tabela estava em fim de arquivo (MODO EOF).

Esta inconsistência pode acontecer nas situações abaixo:

1º Customizações / Personalizações em seu ambiente.

Algumas personalizações utilizam os comandos dbSeek, MsSeek, dbGoTo e etc. que desposicionam os registros de tabelas utilizadas nas rotina do produto padrão causando o problema de "EOF Stack em MSRLock". Para este caso recomendamos que utilize um RPO limpo sem customizações para verificar se o problema esta sendo causado por alguma personalização.

Caso não seja possível utilizar um repositório limpo o cliente poderá habilitar em seu ambiente a chave IXBLOG=NORUN (Para informações acesse: http://www.tdn.totvs.com.br/display/public/mp/Chave+IXBLOG)

Alterar a linha de comando IXBLOG=LOGRUN para IXBLOG=NORUN

Simular o processo e verificar se a inconsistência permanece.

Após a execução do procedimento a linha criada no *.INI do server deve ser removida, pois pode causar baixa performance no sistema se mantida.

2º Registro Bloqueado por outros Usuários

É possível identificar qual o usuário esta segurando a reserva do registro através da ferramenta DBACCESS Monitor.

DBAccess - Monitor > Aba Usuários > Locks

Em algumas situações a reserva de registros pode ocorrer devido a utilização de serviços que ficam executando operações em seu ambiente (JOBs), neste caso recomendamos que desative esses serviços e refaça os testes afim de verificar se o causador do incidente.

3º Configurações e Parametros que auxiliam na resolução da reserva de registros

2º - verificar se o arquivo msrlock.eof gravado na pasta system existe alguma customização no sistema que envolva o alias apresentado na mensagem. Realizar este procedimento de teste em ambiente de homologação onde ocorra o problema ou em ambiente exclusivo (logo em seguida de ter reiniciado o servidor - antes da primeira reprodução do erro):

Se erro persistir mesmo no teste "B", seguir o terceiro procedimento:

 Se erro persistir, seguir o próximo procedimento:

MV_GNRENF - Caso esteja habilitado, recomendamos desabilita-lo (MV_GNRENF = .F.)

MV_FATTRAV - Nossa recomendação e utilizar esse parâmetro.
http://tdn.totvs.com/pages/viewpage.action?pageId=233753699

4º Atualizar o ambiente e realizar novos testes

Certificar-se de estar com últimas atualizações do Portal do Cliente. Caso não, em ambiente de homologação, aplicar último RPO, Binarios, DBACCESS e LIB e verificar se corrige o problema.

5º -

Verificar se há customizações na Estrutura do Protheus, como por exemplo, Índices (SIX) ou gatilhos (SX7).

Realizar backup dos arquivos na Pasta System e recriar com um dicionário de dados padrão. Refazer o processo.

Importante: Os procedimentos indicados são utilizados para rastrear a possível causa da reserva do Alias. Caso ainda ocorra reserva indevida, apesar dos procedimentos, será necessário solicitar auxilio

da equipe de Suporte Investigativo TOTVS para que acesse remotamente a sua base, visando avaliação/ debug da rotina para investigá-la e identificar a origem do problema.