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

...

Produto:

Microsiga Protheus®

Ambiente:SIGAFAT - Faturamento

Ocorrência:	Mensagem: Tentativa de reservar registro no Alias

Xem

X em EOF Stack de chamadas em MSRLOCK.eof Controle de transaçoes Habilitado Tenta novamente ? Essa mensagem sera fechada em 5 segundos Image Modified

Mensagem

Conceito:

O registro número X do Arquivo X encontra-se Bloqueado por outro usuário.

Image Removed

O controle de transação é uma ferramenta importante que garante a integridade de dados quando uma determinada operação é realizada no Banco de Dados. O Protheus possui o parâmetro MV_TTS que quando ativado garante que este processo exista nos processos críticos de transação de arquivos Detalhes: Controle de Transação - MV_TTS As alternativas existentes quando da atualização de tabelas são: Efetivar a transação - quando realizada com sucesso Voltar a status anterior (rollback) - desfaz toda a transação iniciada quando o final da transação não foi concluído com sucesso. Isto garante a total integridade dos dados.

CASO 1

EOF Stack em MSRLOCK

A mensagem "EOF Stack em MSRLOCK" indica que a rotina tentou reservar um registro para ser manipulado

,

no processamento; mas o ponteiro da tabela estava em

fim de arquivo OBS:

FIM DE ARQUIVO (MODO EOF) pois não localizou o dado procurado

.

na Tabela. Ou seja, algum dado (relacionado a este registro que está sendo processado) está inválido / não foi localizado, apresentando quebra de integridade.

É gravado um arquivo de log denominado msrlock.eof na pasta system. Para

a

uma correta conferência, deve-se realizar o processo com a ocorrência em ambiente de homologação onde ocorra o problema, após apagar este registro (para eliminar dados gravados anteriormente).

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

1º Dado incorreto relacionado ao registro

Pode ocorrer de o registro que está tentando manipular possuir um código inválido amarrado a ele. Por exemplo, se for um Pedido de Venda/ de Compra pode ocorrer de

Dica title EXEMPLO Suponhamos que a mensagem ocorre ao tentar gerar / excluir um Doc. de Saída. Então algum dado relacionado com esse Doc de Saída está inválido / não foi localizado, apresentando quebra de integridade. Pode por exemplo ser algo inválido no cadastro do TES utilizado no Pedido de Vendas; pode ser o código do Cliente / Fornecedor / Loja estar

apontando

registrado um código inválido, que não existe

. Ou

; pode conter um código de Produto no grid, ou um código de condição de Pgto, ou o código do Item, ou outro dado qualquer o qual não existe/ não é válido etc. Exemplo:

Procedimentos:

Aviso title 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. Deck of Cards startHidden false effectDuration 0.5 id Custo Médio effectType horizontal loopCards true Card default true id Etapa 1 label Etapa 1 - Rastreamento do dado incorreto relacionado ao registro É necessário rastrear especificamente no ambiente para identificar qual registro da base está com o problema. Deste modo, a primeira análise é avaliar se os registros que está tentando processar possuem dados válidos no Banco, principalmente para a Tabela apontada no alerta e as relacionadas ao processo executado. Recomenda-se realizar simulações para isolar o problema / o registro. Exemplo, inserir um registro idêntico na base de dados e verificar se o registro é gravado nas tabelas com os mesmos dados e se o problema também ocorre. Este tipo de informação incorreta pode ter sido incluído ou por manipulação de dados no Banco (procedimento este não indicado) ou pela própria rotina sem ter ocorrido a

devida

validação adequada (possivelmente devido à uma das causas mencionadas abaixo).

Card default true id Etapa 1 label Etapa 2 - Ver

2º

Customizações/Personalizações em seu ambiente

.

Personalização por Ponto de Entrada: 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 para o teste, é necessário habilitar em seu ambiente a chave IXBLOG=NORUN (Para informações acesse: http://www.tdn.totvs.com.br/display/public/mp/Chave+IXBLOG) Registrar a linha de comando IXBLOG=NORUN no ini do server dentro da sessão do ambiente 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. OBS: Caso ainda assim permaneça, é gravado um arquivo de log denominado msrlock.eof na pasta system. Para a correta conferência, deve-se realizar o processo com a ocorrência em ambiente de homologação onde ocorra o problema, após apagar o arquivo já gravado no diretório (para eliminar dados gravados anteriormente). Personalização por Dicionário de Dados:

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 a atualizado. Refazer o processo.

Card default true id Etapa 1 label Etapa 3 -

3º Importante:

Inconsistência na rotina possivelmente causada por atualizações incompatíveis no ambiente Certificar-se de estar com últimas atualizações do Portal do Cliente. Em ambiente homologação testar com último RPO, Binarios, DBACCESS, LIB e pacote quinzenal de atualizações. Verificar se neste cenário ocorre o problema.

CASO 2

O registro número X do Arquivo X encontra-se Bloqueado por outro usuário

Já a mensagem "O registro número X do Arquivo X encontra-se Bloqueado por outro usuário" indica que a rotina tentou acessar um registro, o qual está reservado por algum processamento de outro usuário.

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

1º Registro Bloqueado por outros Usuários (possivelmente com instância presa)

Obs: Em caso de registro bloqueado por outro usuário, uma opção paliativa rápida é reiniciar o servidor (parando os serviços do TOP, Banco de dados e Server)

Para identificação de causa da ocorrência é necessário identificar qual o usuário está segurando a reserva do registro através da ferramenta DBACCESS Monitor.

DBAccess - Monitor > Aba Usuários > Locks

Image Removed

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.

2º Parâmetros que auxiliam na resolução da reserva de registros

MV_GNRENF - Caso esteja habilitado, recomendamos desabilita-lo (MV_GNRENF = .F.)
MV_FATTRAV - (Nossa recomendação é utilizar esse parâmetro): TUPKT5_DT_Criação do Parâmetro MV_FATTRAV

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

Personalização por Ponto de Entrada:
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 para o teste, é necessário habilitar em seu ambiente a chave IXBLOG=NORUN (Para informações acesse: http://www.tdn.totvs.com.br/display/public/mp/Chave+IXBLOG)
Registrar a linha de comando IXBLOG=NORUN no ini do server dentro da sessão do ambiente
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.
OBS: Caso ainda assim permaneça, é gravado um arquivo de log denominado msrlock.eof na pasta system.
Para a correta conferência, deve-se realizar o processo com a ocorrência em ambiente de homologação onde ocorra o problema, após apagar o arquivo já gravado no diretório (para eliminar dados gravados anteriormente).
Personalização por Dicionário de Dados:
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 a atualizado. Refazer o processo.

Aviso title AVISO IMPORTANTE

Há procedimentos incisivos ao sistema em alguns dos processos mencionados, que devem ser realizados por sua Equipe de TI e, aconselhamos que caso tenha alguma dúvida no processo, solicite acompanhamento de um consultor

Totvs!

TOTVS. Os procedimentos indicados são utilizados para rastrear a possível causa da ocorrência. Caso ainda ocorra apesar da devida realização 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

.Observações:

Pontos de Entrada que permitem desativar o LOCK de registros das tabelas:

Ao desligar o LOCK de registros das tabelas poderá permitir divergências dos campos de controle devido movimentar o registro durante o processamento. Avalie criteriosamente o uso de Pontos de Entrada com esta finalidade.

MT410TRV - Liberação da trava de registros para as tabelas SA1/SA2/SB2

M461TRV - Libera a trava dos registros da tabela SB2

Caso esteja com problemas de Locks nas tabelas SB2 e SA1 recomendamos a leitura da documentação abaixo:

DOC0033_Bloqueio_Pedido_de_Venda_x_Tela_GNRE_Documento_de_Saída
http://tdn

.

totvs.com/pages/viewpage.action?pageId=235336214