Histórico da Página

...

Alguns drivers ou RDDs, como a "TOPCONN" por exemplo suporta operações com transacionamento. Uma vez iniciada a transação, novos registros e alterações feitas nas tabelas abertas pela RDD somente serão efetivadas na base de dados após a finalização com sucesso (ou COMMIT) da transação. A visibilidade dos dados alterados durante a transação por outro processo depende do nivel de isolamento (DBAccess - Isolation Level) utilizado para o Banco de Dados. A maioria dos bancos de dados, por questões de adequação de comportamento com as aplicações AdvPL usam um nivel de isolamento que permite outros processos ler novos registros e conteúdos de registros alterados dentro de um processo transacionado, mesmo antes da transação ser efetivada (ou comitada) no banco de dados. A RDD TOPCONN permite o controle explicito de transacionamento através da função TCCommit(). O ambiente AdvPL usado por exemplo no ERP Microsiga delimita um bloco transacionado usando os comandos BEGIN TRANSACTION e END TRANSACTION. 

Filtros e Visibilidade logica de registros

Uma tabela aberta em modo ISAM pelo AdvPL está sujeita a um comportamento de visibilidade lógica, onde um filtro pode limitar o escopo de regitros visíveis. Desse modo, as funções de navegação somente vão encontrar ou posicionar em registros logicamente visíveis. Por exemplo, uma determinada tabela utilizando um indice e um filtro, ao executar a função DBGotop(), deve posicionar no primeiro registro visível pelo filtro na ordem atualmente em uso. A função DBSeek() – busca por indice – também respeita a visibilidade lógica de um filtro. Uma busca informando uma expressao parcial – que nao contempla todos os campos do índice — somente vai posicionar em um determinado registro caso ele atenda a condição de filtro. No momento que definimos um filtro para a tabela, o registro atualmente posicionado permanece posicionado. Somente a próxima instrução de navegação vai avaliar o filtro. Por isso, normalmente após aplicarmos um filtro em uma tabela, usamos a função DBGOTOP() para localizar e posicionar no primeiro registro que atenda a condição estabelecida, e podemos percorrer todos os registos atendidos pelo filtro com um loop While !Eof() – DbSkip() – Enddo 

Índices com expressão de filtro 

A criação de índices permite o uso de índices temporários, onde é possíve linformar uma expressão de filtro na criação do índice, para que somente sejam ordenados no índice os registros que atendam a esta condição. Os drivers baseados em implementação ISAM nativa – como DBF e CTREE – criam este índice fisicamente, permitindo que o processo atual que usa o índice criado navegue muito mais rapidamente pelos registros contemplados pelo indice do que simplesmente navegar pela tabela filtrada. A RDD TOPCONN contempla esse comportamento sem criar um indice fisico na base de dados. A função IndRegua() do Framework AdvPL do ERP Microsiga internamente se utiliza deste recurso para permitir criar índices temporários filtrados. 

RDD TOPCONN - Comportamentos diferenciados - Queries

Como a RDD TOPCONN atua sobre tabelas criadas através do DBAccess, existem funções especificas adicionais para esta RDD, que atuam sobre as tabelas em modo ISAM e diretamente no banco de dados envolvido, sendo possivel por exemplo a execução de queries para leitura de dados e execução de instruções SQL repassadas ao Banco de Dados. A abertura de uma Query no AdvPL é encapsulada pelas funções TCGenQry e TcGenQry2, onde o result-set da Query é aberto sob um ALIAS AdvPL, que possui algumas restrições de comporamento: O Alias aberto por uma QUERY é internamente aberto em modo somente letitura  (READ ONLY) e suporta a navegação apenas pelas instruções DBSKIP() – com valor positivo, leitura sempre dos próximos registros. Um ALIAS de uma Query não suporta filtros, DBSKIP para registros anteriormente lidos. O Alias de uma Query reflete um result set obtido pelo banco de dados no momento da execução da Query. A única forma de voltar para um registro já lido de uma Query é voltar para o primeiro registro ( dbgotop() ) – POREM internamente este processo re-submete a Query para o banco de dados, e o result set retornado pode ser diferente, caso algum processo tenha inserido ou alterado registros.