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

Produto:

Microsiga Protheus®

Ocorrência:

Passo a passo:

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

2º Incidentes em sua base de dados

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

DBAccess - Monitor > Aba Usuários > Locks

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.