Estrutura das tabelas:
ITENS_PEDIDO
  IT_COD    NUMBER(5),
  PROD_COD  NUMBER(5),
  QUANT     NUMBER(10,2)

PRODUTO
  PROD_COD  NUMBER(5),
  PROD_DSC  VARCHAR2(60)

POUCO EFICIENTE

Podemos usar a trigger POST_QUERY, que é disparada em cada linha do bloco. Dentro desta trigger, coloca-se uma consulta assim:

select prod_dsc
into :BLOCO_ITENS_PED.PROD_DSC
from produto
where prod_cod=:BLOCO_ITENS_PED.PROD_COD;

Este select rodará em cada linha do bloco, buscando a descrição do Produto. Temos que deixar a propriedade do item Database Item No.
Isto é pouquíssimo eficiente! Imaginem se o bloco for buscar 500 linhas? O cliente vai fazer 500 consultas de descrição!!! Resultado: Queda de performance do banco, trafego inútil na rede, etc.

MUITO EFICIENTE

Vamos basear nosso bloco numa View! Como fazemos isso?

1. Criamos uma VIEW_ITENS_PEDIDO com a descrição do Produto.

create or replace view VIEW_ITENS_PEDIDO as
select
  a.*,
  b.prod_dsc
from
  itens_pedido A,
  produto      B
where a.prod_cod=b.prod_cod

2. Criamos o bloco com base nesta view. Agora vamos tornar esta view “alterável”
3. Na propriedade do bloco DML Data Target Name, colocamos o nome da tabela onde será feita a alteração. (no caso, a própria ITENS_PEDIDO)
4. Vamos definir agora qual será o campo chave da tabela. Clicamos no item IT_COD, e vamos para a propriedade Primary Key. Colocamos YES nela.
5. Agora vamos dizer ao Forms que o campo PROD_DSC não faz parte da tabela! Alteramos a propriedade Query Only para Yes!
E Pronto!!!
Agora o Forms sabe que o campo PROD_DSC não deve ser gravado quando a tabela for modificada. Ele sabe que este campo não pertence diretamente a ITENS_PEDIDO!

Comente aqui