Histórico da Página
...
| Expandir | ||
|---|---|---|
| ||
Incidente: Lentidão na comunicação do Logix, entre Appserver e banco de dados SQL Server, ambos em Linux. Solução: Ajustado dbsrv.so para uma comunicação mais eficiente. Referente ao chamado: DTAPPSRV-8019 |
| Expandir | ||
|---|---|---|
| ||
Incidente: Lentidão na comunicação do Logix, entre Appserver e banco de dados SQL Server, ambos em Linux. Solução: Ajustado dbsrv.so para uma comunicação mais eficiente. Referente ao chamado: DTAPPSRV-8019 | ||
| Expandir | ||
| ||
Incidente: A função GetUserInfoArray não retornava dados na posição 4 quando da utilização do broker. Solução: Correção na GetUserInfoArray para preenchimento dos dados corretamente para retorno na função. Referente ao chamado: DTAPPSRV-8053 |
| Expandir | ||
|---|---|---|
| ||
Incidente: Durante a geração de relatorios no Logix, com Appserver em Linux e banco Informix, apresentava quedas esporadicamente. Solução: Adicionado proteções no Appserver para evitar possíveis invasões de memoria. Referente ao chamado: DTAPPSRV-8067 |
| Expandir | ||
|---|---|---|
| ||
Incidente: falha na tradução SQL impactando na execução de trigger em banco Oracle. Solução: ajustes na engine de translate para correta tradução do comando SQL. Referente ao chamado: DTAPPSRV-8103 |
| Expandir | ||
|---|---|---|
| ||
Incidente:Comportamento inesperado de cursor em algumas ocasiões envolvendo banco MSSQL. Solução:Alinhado recursos de MARS desligados com o build 32 bits. Referente ao chamado: DTAPPSRV-8104 |
...
| Expandir | ||
|---|---|---|
| ||
Incidente: No SQL BLOCK Logix, o paraser não reconhecia nomes com o símbolo "$" no meio (gv$session, por exemplo) como nome de tabela, que existem no Oracle; e o parser não reconhece uma variável com nome de tabela caso tivesse o terminador ";" . Solução: Corrigido o parser do SQL BLOCK Logix para a correta identificação dos casos citados. Referente ao chamado: DTAPPSRV-8127 |
| Expandir | ||
|---|---|---|
| ||
| Expandir | ||
| ||
Incidente: ocorrência de cursor não encontrado em banco SQL Server. Solução: ajustes e melhorias na engine de controle de cursores. Referente ao chamado: DTAPPSRV-8130 | title | DTAPPSRV-8163
| Expandir | ||
|---|---|---|
| ||
Incidente: A função FErase está conseguindo apagar um arquivo que foi criado pela FCreate, mas que não foi fechado. Esse problema acontece em ambiente virtualizado com VMWare. Solução: Corrigido a forma de criar arquivos na função FCreate para que não seja possível a exclusão de arquivos não fechados. Referente ao chamado: DTAPPSRV-8182 |
| Expandir | ||
|---|---|---|
| ||
Incidente: ocorrência de "Access violation" na função isCursorDeclared. Solução: ajustes nos tratamentos de parâmetros da função. Referente ao chamado: DTAPPSRV-8183 |
| Expandir | ||
|---|---|---|
| ||
Ocorrência: durante compilação, ocorria Access Violation no Application Server. Solução: foram realizados ajustes na camada de debug ADVPL. Referente ao chamado: DTAPPSRV-8184 |
| Expandir | ||
|---|---|---|
| ||
Incidente: Memory leak em windows durante checagem de assinatura de fontes prw ou tlpp. Solução: Limpeza de recursos SSL que prendiam a memória. Referente ao chamado: DTAPPSRV-8194 |
| Expandir | ||
|---|---|---|
| ||
Incidente: comando DECLARE adiciona cursor em lista de controle mesmo quando ocorre falha. Essa ocorrência afeta apenas os bancos Oracle e SQL Server. Solução: ajuste no tratamento de erro para os bancos Oracle e SQL Server que em decorrência do comportamento dos bancos, afetava o tratamento de erro na plataforma. Referente ao chamado: DTAPPSRV-8218 |
| Expandir | ||
|---|---|---|
| ||
Incidente: Ao ocorrer uma excessão, o console.log mostra linhas negativas Solução: Correção no tramento das linhas do fonte para correta exibição Referente ao chamado: DTAPPSRV-8222 |
...
| Expandir | ||
|---|---|---|
| ||
Incidente: função TCGetInfo(5) retornando informações de memória incompletas, trazendo apenas parte das informações. Solução: o buffer size que estávamos utilizando tinha o tamanho de apenas 1024, o que era insuficiente. A capacidade do buffer foi aumentada. Referente ao chamado: DTAPPSRV-8261 | ||
| Expandir | ||
| ||
Referente ao chamado: DTAPPSRV-8266 |
| Expandir | ||
|---|---|---|
| ||
Incidente: Quando utilizado o tlppREST ou REST 2.0 e utilizar uma API com retorno com chunk com necessidade de conversão de Encode CP1252 para UTF-8 estava ocorrendo um duplo encode caso na camada do produto já tivesse sido feito ocasionando erro na codificação. Solução: Foi realizado um ajuste no AppServer para evitar que ocorra um duplo encode em caso de Chunk, portanto quando a camada do produto já tiver realizado o processo de Encode a camada da aplicação (AppServer) não o efetuará em todas as instâncias do Chunk, e caso contrário o Apperver efetuará a conversão igualmente em todos os pacotes de Chunk. Referente ao chamado: DTAPPSRV-8269 |
...