Histórico da Página

Produto:

Microsiga Protheus

Ocorrência:

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.

Passo a passo:

Esta é uma ocorrência que não é reproduzida, indevidamente, em ambiente padrão atualizado. Está geralmente sujeita ao cenário do cliente. Asim, é preciso rastrear possíveis causas.

A mensagem referente a EOF Stack em MSRLOCK indica que o registro em questão está reservado por outro processo.

Esta inconsistência pode acontecer em duas principais situações:

1º o uso do registro por outro usuário e 2º uma customização / processo que iniciou indevidamente o tratamento e unlock do registro.

Para: 'Uso do registro por outro usuário' é possível identificar qual o usuário, analisando os looccks de cada usuário conectado, na ferramenta:

DBAccess - Monitor > Aba Usuarios > Loocks

Para: 'Customização / processo que iniciou indevidamente o tratamento e unlock do registro' segue sequência de verificações / procedimentos a realizar:

1º - reiniciar o servidor (parando os serviços do TOP, Banco de dados e Server) e realizar novos testes.

 Se erro persistir, seguir o segundo procedimento:

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

A) Anexar o arquivo criado pelo comando IXBLOG:

No arquivo *.INI do Server, no ambiente que fará o teste, adicionar a linha: IXBLOG=LOGRUN ao final das configurações do ambiente e salvar.

Ao entrar no sistema será apresentada a mensagem "USER FUNCTION debug is active, you will have performance cost", isso significa que o sistema está rodando o IXBLOG. Caso a mensagem não seja apresentada revise o processo no *.INI, e posteriormente baixe e suba o Server.

Simular o processo até que gere a inconsistência citada.

Na pasta Protheus_Data será criada a pasta IXBLOG e, dentro desta, um arquivo *.LOG com seu nome de usuário e registro de Pontos de entrada/Customizações identificadas no processo, para análise.

B) Testar retirando influencia de Customizações e Pontos de Entrada:

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.

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

3º - dropar o alias e os arquivos *.cdx (realizando backup, deixando a tabela ser recriada e appendando os registros do bakcup) e realizar novos testes.

 Se erro persistir, seguir o próximo procedimento:

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

 Se erro persistir, seguir o próximo procedimento:

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 de Consultoria Totvs para que acesse remotamente a sua base, visando avaliação/ debug da rotina para investigá-la e identificar a origem do problema.