Incidente: Uma falha de obtenção de lock de inserção no dbaccess pode levar ao erro "-31 Update Without Lock". Ocorrência reproduzida em cenários de inserções concorrentes em tabelas com numeração automática no banco de dados, onde um outro job consegue obter um lock de alteração antes do dbaccess realizar o lock de inserção.

Melhoria : A mensagem de falha de lock de inserção, registrada no log de console do dbaccess, vai mostrar detalhes do outro job que conseguiu obter o lock de alteração antes do dbaccess obter o lock de inserção. Essa informação será util para determinar as ações a serem tomadas para evitar este cenário.

Referente ao chamado: TPGW-1541

Incidente: Ao conectar o DBMonitor em um DBAccess Secundário, abrir a aba Usuários e depois mandar o DBMonitor conectar em um DBAccess Primário, o DBMonitor não exibe o botão para alternar a exibição de dados de Secundários. Além disso, ao trocar para a exibição de dados de Secundário, o DBMonitor encerrava abruptamente.

Solução: Corrigido no DBMonitor o comportamento do botão para alternar para exibição de Secundário e a exibição dos dados de secundários.
Referente ao chamado: TPGW-1564

Incidente: Retornar campos memo em Query precisava ser configurado por cada conexão pelo AppServer, usando por exemplo a função TCCONFIG()

Solução: A partir dessa build, o dbaccess por default retorna campos memo de queries solicitadas ao DBAccess, desde que o(s) campo(s) memo seja(m) o(s) último(s) campos do select. O valor default da configuração MEMOINQUERY passa a ser '1' ( Habilitado ).

Referente ao chamado: TPGW-1672

Incidente: Tabelas de scheduler sendo dropadas do banco de dados mesmo ainda em uso, causando erros de objeto inexistente e erro na preparação de statements no DBAccess.

Correção: Corrigida a falha na geração de um identificador interno. Essa falha esporadicamente limpava o controle de aberturas de tabelas, permitindo inadvertidamente que uma rotina de limpeza de tabelas do scheduler fosse executada mesmo com a tabela em uso.

Referente ao chamado: TPGW-1738

Solicitação: Habilitar a comunicação do DBAccess com o Log Server, funcionando como um Log Client.

Solução: Implementado mecanismo de Log Client para o DBAccess.
Referente ao chamado: TPGW-1536

Incidente: Uso da configuração PARTKEY não se aplica a tabelas temporárias.

Correção: A configuração interna PARTKEY não será acrescentada na criação de tabelas temporárias, para MSSQL, ORACLE e POSTGRES.
Referente ao chamado: TPGW-1537

Solicitação: Remover a limitação do tamanho das listas retornadas pela TCGetInfo().

Solução: Fizemos um ajuste no DBAccess e removemos o limitador de tamanho para os slots que retornam listas de dados, vide: https://tdn.totvs.com/x/r-VUE^{Image Added}.
Referente ao chamado: TPGW-1657

Solicitação: Atualização da bibliotecas utilizadas pelo DBAccess.

Solução: Bilbiotecas de criptografia e memória atualizadas.
Referente ao chamado: TPGW-1668

Solicitação: Implementar uma forma de indicar quais tipos de conexões a TCQuit deve encerrar

Solução: Fizemos uma mudança na TCQuit (https://tdn.totvs.com/x/sH4PE^{Image Added}) que agora pode receber um novo parâmetro numérico para determinar seu comportamento.

Ajuste na TCQuit, agora ela pode receber uma parametro numérico para determinar o comportamento de desconexão das threads.

0 = encerra todas as conexões
1 = encerra conexões de dados, mas mantém as conexões de controle de numeração automática e lockbyname (default)
Referente ao chamado: TPGW-1675

Solicitação: Eventuais erros -2 em algumas conexões do TOTVS Application Server para o DBAccess, em situação de stress – muitas conexões ao mesmo tempo de um ou mais TOTVS Application Server sendo realizadas no mesmo instante.

Solucação: O valor default e minimo de threads em espera para aceite de conexões no DBAccess foi aumentado para 100. Com isso, independente do montante atual de conexões, o DBAccess vai procurar manter sempre 100 processos livres para o atendimento de novas conexões, vide https://tdn.totvs.com/x/ZG3yHg^{Image Added}.
Referente ao chamado: TPGW-1704

Solicitação: Uma alteração envolvendo um campo que faz parte de uma estatistica criada explicitamente no banco de dados MSSQL falhava com o erro "5074 | The statistics <statictic_name> is dependent on column <field_name>"

Melhoria: Antes de tentar alterar o campo, o DBAccess identifica e elimina quaisquer estatisticas criadas explicitamente no banco de dados para a alteração ser possível.
Referente ao chamado: TPGW-1711

Incidente: A configuração LockTimeOut informa que os valores configurados são expressos em segundos. Porém, ao passar a informação para o banco Postgres, ele estava considerando o valor informado como milissegundos.

Correção: A partir da build atual, o valor informado na configuração LockTimeOut é passado corretamente ao banco Postgres, em segundos.

Para informações adicionais, consulte a documentação da configuração LockTimeOut no TDN, no link https://tdn.totvs.com/x/sw9LHw^{Image Added}
Referente ao chamado: TPGW-1734

Ocorrência: O kernel UEK do Oracle Linux não é homologado/suportado pelo DBAccess e pode causar diversos problemas, por exemplo, quedas, lentidão, entre outros.

Melhoria: Inserida validação do kernel no DBAccess Linux para verificar se o kernel é UEK e impedir a inicialização com a mensagem de erro abaixo:

[ERROR] [DEBUG] *** THE KERNEL VERSION (N.N.N-NNN.el8uek.x86_64) IS UEK AND IT IS NOT SUPPORTED, PLEASE REFER TO THE DOCUMENTATION OF SUPPORTED OPERATING SYSTEMS

Referente ao chamado: TPGW-1740

Ocorrência: Atualizar campos MEMO do tipo CLOB em banco ORACLE utilizando instruções diretas no banco de dados ( como TCSQLEXEC com UPDATE), exigia sempre um caractere ASCII 0 ( zero binário ) no final do conteúdo. Caso esse caractere finalizador não fosse colocado no valor do campo, a leitura do conteúdo do campo CLOB pelo AdvPL ( seja por Tabela ou Query ) removia o ultimo caractere do campo.

Correção: Equalizado o comportamento com os demais bancos de dados. O CHR(0) ainda é gravado pelo dbaccess no banco de dados, mas no momento da leitura, caso esse caractere 0 finalizador não exista, o dado será retornado corretamente , sem remover a ultima letra do conteúdo do campo.
Referente ao chamado: TPGW-1745