Histórico da Página
Versões comparadas
Chave
- Esta linha foi adicionada.
- Esta linha foi removida.
- A formatação mudou.
Pagetitle | ||||
---|---|---|---|---|
|
Correções
Expandir | ||
---|---|---|
| ||
Ocorrência: Quando usado o DBAccess Monitor conectado a um dbacess primário (Master), caso exista um mesmo threadID de conexão em dois dbaccess secundários diferentes, a cada refresh da tela do dbaccess monitor, era selecionado e posicionado na primeira conexão com o ID em foco. Correção : Corrigido no mecanismo de posicionamento de conexão no DBMonitor, para diferenciar as conexões com mesmo ID, e posicionar corretamente. Ref issue TPGW-1318 |
Expandir | ||
---|---|---|
| ||
Ocorrencia: Durante uma inserção de multiplas linhas usando TCDBINSERT em tabela com campo MEMO no banco de dados ORACLE, caso houvesse uma falha de inserção dos campos memo, como por exemplo o limite de um database sem autoextent atingido, o dbaccess registrava o erro Error : 22275 - ORA-22275: invalid LOB locator specified| ( From tDBServer::ROP_DBINSERT ) Correção: O tratamento de erro de inserção de registros no Oracle foi corrigido, para que o erro correto seja mostrado. Ref. issue TPGW-1392 |
Expandir | ||
---|---|---|
| ||
Ocorrência : Assert Exception no DBAccess ao utilizar um campo numérico com definição igual ou superior a 60 dígitos. Solução: Comportamento corrigido. Embora na prática a definição informada não seja suportada, uma vez aceita a definição informada na criação da tabela, não é esperado que o DBAccess apresente um Assert Exception durante o uso da tabela. Referente a ocorrência : TPGW-1397 |
Expandir | ||
---|---|---|
| ||
Ocorrência : DBAccess começou a apresentar mensagens de erros de grants e o Initial Connection Check-Up registra a informação: Has Minimal Grants ........: NO - WARNING: User [XXXX] does not have the minimal grants to use DBAccess. Solução: Correção no DBAccess para a correta identificação de todos os Grants. Referente a ocorrência : TPGW-1375 |
Expandir | ||
---|---|---|
| ||
Ocorrência: Um TCAlter() detabela de tabela com campo S_T_A_M_P_ dropa a trigger que atualiza esse campo. Para bancos de dados Postgres, a sintaxe da instrução DROP TRIGGER não estava correta. Correção: Arrumado o DROP TRIGGER para Postgres usando a sintaxe exigida pelo banco de dados. Informações adicionais: O erro de falha no DROP TRIGGER era registrado no log do DBAccess, mas isso náo não impedia a execução do TCALTER(), que era finalizado com sucesso. Referente a ocorrencia ocorrência : TPGW-1424 |
Expandir | ||
---|---|---|
| ||
Ocorrência : Leitura de campos MEMO no ORACLE , onde o conteúdo gravado é maior que 64KB, ao ler o campo memo com Query via AdvPL, eram retornados 6 bytes a mais no início do campo . Correção : Estes 6 bytes a mais são de uso interno do DBAccess, gravados apenas em campos memo para ORACLE, quando o tamanho do conteúdo do campo excede 64KB, e deve ser removidos pelo DBAccess ao retornar o conteúdo do campo memo para o AdvPL. Referente a ocorrência : TPGW-1429 |
Expandir | ||
---|---|---|
| ||
Ocorrência : Cópia de tabelas usando o Migrador do DBTOOLS, builds 21.1.1.5 e superiores, com a opção de criação de índices no destino, adicionava indevidamente o campo de controle R_E_C_D_E_L_ como antepenultimo campo chave, causando erro interno de abertura do índice no AdvPL, Correção: Corrigida análise da expressão de índice, para remover os campos de controle antes de enviar a instrução de criação de índice no database de destino. Referente a ocorrência : TPGW-1417 |
Expandir | ||
---|---|---|
| ||
Ocorrência: Em um ambiente com DBAccess Distribuído, parar um serviço de um ou mais DBAccess secundários poderia gerar uma inconsistência na contagem de conexões licenciadas, informando um número negativo no DBAccess Monitor conectado no DBAccess Master. Correção: Corrigido o mecanismo de decremento de conexões do DBAccess secundário. Referente a ocorrência : TPGW-1413 |
Expandir | ||
---|---|---|
| ||
Ocorrência: Em ambiente Oracle, quando a utilização do campo S_T_A_M_P_ está habilitada, a execução do comando ZAP poderia apresentar uma mensagem de erro do Banco de Dados, indicando que a criação de um índice falhou, pois o mesmo já existe. Correção: Fizemos um ajuste no TOTVS | DBAccess para que o índice só seja criado caso ele realmente não exista. Referente a ocorrência : TPGW-1408 |
Melhorias
Expandir | ||
---|---|---|
| ||
Ocorrência: Foi identificado um cenário de uso da tabela TOP_PARAM, onde a criação de um segundo índice apresentava melhora de desempenho. Melhoria: Além da criação de um novo índice automaticamente para a tabela TOP_PARAM, foi implementada uma verificação dos indices das tabelas internas do DBAccess, e criação automática dos indices das demais tabelas internas, caso não existam. Referente a issue TPGW-1187 |
Expandir | ||
---|---|---|
| ||
Ocorrência: Quando algumas instruções de busca sobre índice (função AdvPL DBSEEK) eram executadas em tabelas filtradas, eventualmente o plano de execução da query poderia ser reaproveitado inadequadamente pelo Banco de Dados MSSQL, resultando em um baixo desempenho da execução da query. Melhoria: Neste cenário, o DBAccess passa a enviar um hint para o MSSQL, para refazer o plano de execução da Query. Observações:
|
Expandir | ||
---|---|---|
| ||
Ocorrência: Congelamento ou elevado consumo de recursos quando executada a query de identificação de tabelas temporárias órfãs para o banco de dados ORACLE. Melhoria: O DBaccess passa a obter os dados das tabelas temporárias e das conexões ativas em duas queries mais leves, ao invés de uma única query, para identificar as tabelas temporárias ainda existentes, que não estão relacionadas a nenhuma conexão ativa para serem eliminadas do banco de dados. Ref. issue TPGW-1416 |
Expandir | ||
---|---|---|
| ||
Ocorrência : Ao iniciar os processos, algumas threads do dbaccess falham no initial checkup, com um erro de concorrência no potsgres. Cada dbaccess slave faz o seu Initial Checkup no banco, e se as primeiras conexões forem concorrentes, como ele não verifica se a function round() já existe – que o dbaccess cria no banco para atender a necessidades do AdvPL – e dispara um "create or replace function", o banco retorna um erro se multiplas conexoes tentam fazer issso ao mesmo tempo .. Correção: Cria as funções round() no Postgres para o AdvPL SILENCIOSAMENTE, sem registrar ou reportar erro, ou invalidar o Initial Checkup, e não tenta fazer REPLACE da função , apenas criar a função. Ref. issue TPGW-839 |
Novas Implementações
Painel |
---|
Veja também |