Histórico da Página
Composition Setup |
---|
import.css=/download/attachments/327912/newLayout.css |
Portuguese | ||||||||
---|---|---|---|---|---|---|---|---|
Ctree Error 160 - Multi-user interference************************ (SERVER,User) ************************ <oper> - Ctree Error 160 - IO Error: <x> - Multi-user interference: key value changed between index search and subsequent data record read. File: <file>
Partindo de um ambiente onde duas aplicações abrem a mesma tabela em modo compartilhado, a aplicação 1 cria um índice temporário com condição de filtro, e faz uma pausa. Enquanto isso, a aplicaçao 2 realiza uma alteração em um registro da tabela, que fazia parte dos registros selecionados na condição de filtro do índice criado e utilizado pela aplicação 01 ou o campo alterado fazia parde da chave de indexação usada no índice temporário. Em um ambiente DBF/ADS, sabemos que uma alteração realizada na aplicação 2 não tem nenhuma interferência na navegação sobre o índice temporário em uso pela aplicação 1. Pois afinal, a aplicação 2 não estava com o índice temporário aberto, e a aplicação 1 continua navegando no índice por ela criado e apenas por ela atualizado, mesmo que uma outra aplicação tenha alterado um campo que tornaria o registro não mais válido para a condição de filtro estipulada pelo índice temporário em uso pela aplicação 1. Quando trabalhamos com tabelas c-tree, se uma situação dessas acontece, e a aplicação 1 vai navegar no índice temporário, após a alteração realizada pela aplicação 2 em um campo que interfira na condição de visibilidade do registro ou ordem de navegação, o c-tree considera isto uma interferência em ambiente multi-usuário (Multi-User Interference). Esta é uma característica dos índices temporários c-tree, que aborta a aplicação durante a navegação no índice temporário da aplicação 1 (Caso 1). Esta ocorrência também pode ser reproduzida, caso a mesma aplicação que criou o índice temporário fechá-lo, realizar uma alteração na tabela que interfira em campos chave ou condição do mesmo índice, e reabri-lo para posterior utilização (Caso 2). Caso uma ocorrência destas seja reproduzida, deve-se determinar quais as rotinas que estão sendo executadas simultaneamente pela aplicação, pois uma delas está interferindo no funcionamento da outra. Se a execução de apenas uma rotina isolada está causando o erro, é bem provável que a rotina esteja realizando uma alteração em registro significativo na chave ou condição do índice com o mesmo fechado, e abrindo novamente o índice para navegação (Caso 2). Para ilustrar melhor as diferenças e os efeitos desta característica, foram realizados testes com as operações básicas pela aplicação proposta neste documento, e seus respectivos resultados em ambientes ADS e c-tree:
Inserção de novo registro na tabelaAplicação 1 - Cria índice temporário filtrado e aguarda.
Update de campo CHAVE do índiceAplicação 1 - Cria índice temporário filtrado e aguarda.
Update de campo da condição de filtroAplicação 1 - Cria índice temporário filtrado e aguarda.
Exclusão física de registro da tabela com índice fechado- ADS : Aborta a aplicação com erro de 'skip' : Invalid Record Number
|