Chiappa, decidi seguir em frente com a external table. No fim do
processamento eu pego o conteúdo do log e do bad file, mostro no fim do log
do concurrent e depois apago esses 2 arquivos.
Não sei se você tem experiência com Oracle EBS mas não faria sentido
construir uma tela só para isso. Eu já
Então Chiappa, eu não conhecia não. Já tinha utilizado o SQL LOADER,que é
bem parecido com esse recurso da external table, que utiliza o
ORACLE_LOADER.
Logo que o Alexandre comentou sobre a external table, troquei uma ideia com
ele.
Realmente é uma alternativa bem interessante, o único porém é a
Então : veja que tanto a EXTERNAL TABLE quanto a operação de MERGE que eu
recomendo como sendo (e na Esmagadora maioria das vezes é MESMO) mais Rápida
são built-ins, nativos DO DATABASE, então por isso se por um lado te dão a
performance TOP (internamente elas são código C , ** compilado **
Então Chiappa, até montei um script aqui pra testar a external table, está
funcionando certinho.
Mas acho que realmente terei que fazer algo para avaliar
registro-a-registro, pra indicar no log do concurrent a situação de cada
registro.
Eu até poderia continuar usando o external table pra
Bem, imho a pessoa ** não ** vai ter que usuário vai ter que analisar o log
do concurrent e depois o log do LOADER/external table, pois os logs detalhados
que são gerados para a external table são em caso de EXCEÇÕES (ie, o BADFILE eo
DISCARDFILE), enquanto o LOGFILE propriamente dito tem
Blz ? Então, a opção de carregar os dados do arquivo pra GTT (seja como for,
com SQL ou PL/SQL, bulk ou não, etc), simplesmente ** NÃO FAZ SENTIDO **
frente à opção de EXTERNAL TABLE - não sei se vc a conmhece, mas é uma feature
relativamente antiga que permite que vc use o arquivo-texto
