Não é uma pergunta, visto que já identifiquei a causa. Se alguém passar pela mesma situação.
O seguinte erro me ocorreu ao criar uma tabela temporária com a coluna "DESC". Aparentemente não aceita esse nome. Alterando o nome da coluna não me ocorreu mais o erro.
Bom dia, Estava com esse mesmo problema aqui na empresa, busquei no Google e encontrei esse fórum. Apenas para ajudar os demais, aqui rodamos uma rotina que levou um tempo muito considerável durante a noite, e ficou com transações de COMMIT pendentes (não havia nenhum comando SQL na rotina, e sim comandos de AdvPL que fazem o UPDATE, como RecLock). Porém, como levou muito tempo e era uma quantidade considerável de dados, ele encheu nossa tabela “tempdb”. A solução foi encontrar o SPID e dar um kill via banco de dados.
Esse erro deve ocorrer porque DESC é uma palavra reservada do SQL, usado no Order By. O mesmo deve ocorrer com outras palavras reservadas; como ORDER, ASC, etc.
Boa tarde Giordano, nesse caso não fiz uso de consulta de dados no SQL, somente fiz a população da tabela com dados gerados no próprio fonte.
Você acha que mesmo assim pode ocorrer?
Boa noite, Daniel! Sim, pois internamente o DbAccess irá tentar criar a tabela no banco e popular. Como ela possui campos que o nome é uma palavra reservada, acaba causando esse erro na criação dos dados.
Comigo, estava dando esse mesmo erro no padrão do contas a pagar, quando eu ia incluir um titulo. O problema foi resolvido simplesmente ao reiniciar o servidor!!!
Abraços,
Rodrigo Rosselli
Atenção: Esta publicação foi transferida automaticamente do fórum antigo, mas os anexos não foram incluídos.
Daniel Scheeren, muito obrigado!
Sua resposta foi muito util para descobrir um problema que estava tendo ao tentar criar uma tabela temporaria utilizando a classe FWTemporaryTable.
No meu caso, sempre apresentava "_SC00: Error : 904 - ORA-00904: : invalid identifier" e com sua ajuda descobri que a coluna com nome "DESC" que estava criando, estava causando esse erro.
Estava com esse mesmo problema aqui na empresa, busquei no Google e encontrei esse fórum. Apenas para ajudar os demais, aqui rodamos uma rotina que levou um tempo muito considerável durante a noite, e ficou com transações de COMMIT pendentes (não havia nenhum comando SQL na rotina, e sim comandos de AdvPL que fazem o UPDATE, como RecLock).
Porém, como levou muito tempo e era uma quantidade considerável de dados, ele encheu nossa tabela “tempdb”. A solução foi encontrar o SPID e dar um kill via banco de dados.
Bom dia, Estava com esse mesmo problema aqui na empresa, busquei no Google e encontrei esse fórum. Apenas para ajudar os demais, aqui rodamos uma rotina que levou um tempo muito considerável durante a noite, e ficou com transações de COMMIT pendentes (não havia nenhum comando SQL na rotina, e sim comandos de AdvPL que fazem o UPDATE, como RecLock).
Porém, como levou muito tempo e era uma quantidade considerável de dados, ele encheu nossa tabela "tempdb".
A solução foi encontrar o SPID e dar um kill via banco de dados.