booyaa's questions

spooltest.sql:

SPOOL test.log
CLEAR SCREEN
SET VERIFY OFF
PROMPT Queries will appear in spool
select sys_context('USERENV', 'INSTANCE_NAME') from dual;
PROMPT Output from the HOST command will not
HOST ECHO %COMPUTERNAME%
SPOOL OFF

saída do sqlplus:

Queries will appear in spool

SYS_CONTEXT('USERENV','INSTANCE_NAME')
---------------------------------------------------

wibble

Output from the HOST command will not
AWESOMESERVERNAME

SQL>

teste.log:

Queries will appear in spool

SYS_CONTEXT('USERENV','INSTANCE_NAME')                                          
--------------------------------------------------------------------------------
wibble

Output from the HOST command will not

Se não for possível capturar a saída do HOST, alguém pode sugerir uma solução alternativa.

Estou tentando lidar com duas exceções diferentes que podem ser acionadas em uma tabela externa que lê um CSV.

O código funciona muito bem, mas estou preocupado em estar fazendo errado.

SET SERVEROUTPUT ON;
DECLARE
  records INT := 0;  
  external_table EXCEPTION;
  PRAGMA EXCEPTION_INIT(external_table, -29913);    
BEGIN
  SELECT COUNT(*) INTO records FROM ext_testing;

  EXCEPTION
    WHEN external_table THEN
      IF dbms_utility.format_error_stack LIKE '%KUP-04040%' THEN
        RAISE_APPLICATION_ERROR(-20000, 'Missing CSV file!');
      ELSIF dbms_utility.format_error_stack LIKE '%ORA-30653%' THEN
          raise_application_error(-20001, 'Invalid UTI report, check for missing fields!');
      END IF;      
    WHEN others THEN      
        dbms_output.put_line('An exception occurred');
        dbms_output.put_line(SQLCODE || '=>' || SQLERRM);        
END;

O seguinte gatilho que une a tabela Inserted em si cria vários registros indesejados:

CREATE TRIGGER [dbo].[trFooInsert] on [dbo].[Foo]
AFTER INSERT
AS 
BEGIN
    IF EXISTS(SELECT 1 FROM Inserted a
                LEFT JOIN Inserted b ON b.Flag = 1 AND a.ID = b.ID
                WHERE b.Flag IS NULL AND a.Flag = 0
                ) -- exists
    BEGIN
        INSERT INTO Foo(ID, Etc, Flag)              
        SELECT a.ID, a.Etc, 1 FROM Inserted a
            LEFT JOIN Inserted b ON b.Flag = 1 AND a.ID = b.ID
            WHERE b.Flag IS NULL AND a.Flag = 0
    END -- insert
END -- trigger

Onde como este gatilho que se junta a Inserted on Foo (a tabela à qual o gatilho está vinculado) cria um registro.

CREATE TRIGGER [dbo].[trFooInsert] on [dbo].[Foo]
AFTER INSERT
AS 
BEGIN
    IF EXISTS(SELECT 1 FROM Inserted a
                LEFT JOIN Foo b ON b.Flag = 1 AND a.ID = b.ID
                WHERE b.Flag IS NULL AND a.Flag = 0
                ) -- exists
    BEGIN
        INSERT INTO Foo(ID, Etc, Flag)              
        SELECT a.ID, a.Etc, 1 FROM Inserted a
            LEFT JOIN Foo b ON b.Flag = 1 AND a.ID = b.ID
            WHERE b.Flag IS NULL AND a.Flag = 0
    END -- insert
END -- trigger

O segundo gatilho faz exatamente o que eu quero, mas estou tentando entender porque o primeiro gatilho cria tantos registros. Eu esperava que Inserted e Foo fossem idênticos quando o gatilho fosse acionado. Existe algum tipo de propriedade/comportamento especial que a tabela Inserted exibe ao se unir a si mesma?

Desculpas se não houver informações suficientes, tentei reduzir às diferenças básicas entre os dois gatilhos.

Atualização nº 1

Estou tentando preencher a tabela com registros em que a conta do usuário possui transações, mas não possui o sinalizador definido.

Atualização nº 2

As inserções são realizadas por um aplicativo C#. A fonte de dados é um arquivo simples em que cada linha representa uma única linha na tabela. Não sei se o aplicativo usa pool de conexões ou se isso é importante. As inserções em massa são feitas uma vez por mês. O aplicativo C# geralmente importa 8373 linhas. O primeiro gatilho insere 50 linhas adicionais, há apenas uma linha que eu quero.