Bem, eu nunca vi isso, mas pelo que DEDUZO nessa sintaxe aí o objetivo é
fazer um JOIN da e1 com a e2 E atualizar a coluna da e1 com o valor retornado
na e2 : se é isso, é EXATAMENTE o que o UPDATE com um JOIN como target faz no
Oracle, mudaria só um pouco a sintaxe, seria UPDATE
(joinemquestãocomasduastabelas) SET valores... ao invés de UPDATE tabela1 SET
valores (join)....
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Fabio Prado <fbifabio@...> escreveu
>
> Chiappa, entendi o que vc passou como referência, mas acho que o nosso
> colega está se referindo a fazer parecido com o q vemos no script abaixo,
> que não é padrão ANSI e que eu já fiz coisa parecida no SQL Server quando
> eu era Desenvolvedor e não lembro mais a sintaxe:
>
> UPDATE hr.employees e1
> SET e1.job_id = e2.job_id
> INNER JOIN hr.employees e2
> ON e2.employee_id = e1.employee_id
> WHERE e1.DEPARTMENT_ID = 20;
>
> *ao invés de (o script abaixo funciona no Oracle)*:
> UPDATE hr.employees e1
> SET job_id = ( SELECT e2.job_id
> FROM hr.employees e2
> WHERE e2.employee_id = e1.employee_id)
> WHERE e1.DEPARTMENT_ID = 20;
>
> []s
>
> Fábio Prado
> http://www.fabioprado.net
>
>
> Em 2 de outubro de 2013 10:01, J. Laurindo Chiappa
> <jlchiappa@...>escreveu:
>
> > **
> >
> >
> > Na verdade depende ** exatamente ** do que o colega lá deseja : como eu
> > mostrei na minha msg anterior na thread, se ele quer um UPDATE em que os
> > valores a setar venham de um JOIN é possível SIM, de modo direto, OU se ele
> > quer fazer um UPDATE em múltilas tabelas e/ou atualizar os dados que vêm de
> > um relacionamento (JOIN) é TAMBÉM totalmente possível, usa-se a própria
> > query que contém o JOIN como target do UPDATE, dei uns links que mostram
> > exemplos para isso...
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br, Fabio Prado <fbifabio@> escreveu
> > >
> > > Silvelmar,
> > >
> > > No Oracle não dá para fazer um UPDATE com JOIN. Se vc está fazendo esta
> > > pergunta, acredito que vc já trabalhou com outro BD em que o dialeto
> > > daquele banco permite fazer tal coisa, pois já vi isso no SQL Server.
> > >
> > > No Oracle vc alcançará o mesmo resultado escrevendo um SQL (e não query)
> > > com o UPDATE correlacionado, como no exemplo abaixo:
> > >
> > > UPDATE hr.employees e1
> > > SET job_id = ( SELECT e2.job_id
> > > FROM hr.employees e2
> > > WHERE e2.employee_id = e1.employee_id)
> > > WHERE DEPARTMENT_ID = 20;
> > >
> > >
> > > Att,
> > >
> > > Fábio Prado
> > > http://www.fabioprado.net
> > >
> > >
> > >
> > >
> > >
> > > Em 1 de outubro de 2013 16:42, Silvelmar Martins Gois
> > > <silvelmar@>escreveu:
> > >
> > > > **
> > > >
> > > >
> > > > Boa tarde a todos!****
> > > >
> > > > ** **
> > > >
> > > > Gostaria de ter um exemplo de uma query que faça UPDATE no oracle e que
> > > > tenha JOIN.****
> > > >
> > > > ** **
> > > >
> > > > Agradeço antecipadamente****
> > > >
> > > > ** **
> > > >
> > > > Silvio.****
> > > >
> > > > ** **
> > > >
> > > > *De:* oracle_br@yahoogrupos.com.br [mailto:
> > oracle_br@yahoogrupos.com.br] *Em
> > > > nome de *J. Laurindo Chiappa
> > > > *Enviada em:* quarta-feira, 24 de abril de 2013 20:14
> > > > *Para:* oracle_br@yahoogrupos.com.br
> > > > *Assunto:* [oracle_br] Re: Existe algum insert que segura a inserção de
> > > > dados na tabela inserida****
> > > >
> > > > ** **
> > > >
> > > > ****
> > > >
> > > > E só complementando : execuções paralelas visam principalmente a
> > diminuir
> > > > o tempo de processamento, e CLARO que sempre existe a possibilidade
> > de, ao
> > > > invés de vc ter n sessões simultâneas cada uma lendo um arquivo, via
> > > > EXTERNAL TABLE com parallel SQL vc poderia ter n slave sessions
> > > > lendo/processando/inserindo dados do MESMO arquivo, que logicamente ia
> > > > terminar de ser processado mais rápido e aí mais rapidamente ia ler o
> > > > próximo... Processando-se um arquivo por vez Elimina-se a necessidade
> > de
> > > > controle que é necessária se vc for processar múltiplos arquivos....
> > > >
> > > > []s
> > > >
> > > > Chiappa
> > > > --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" <jlchiappa@
> > >
> > > > escreveu
> > > > >
> > > > > Colega, veja bem : é um FATO que que, se vc abre várias SESSÕES num
> > > > RDBMS, naturalmente os dados inseridos por uma SESSÂO x mas ainda não
> > > > comitados ** não ** podem/não vão poder ser 'enxergados' por uma outra
> > > > sessão y, EM ESPECIAL no RDBMS Oracle aonde nunca, jamais, em tempo
> > algum,
> > > > existe leitura "suja", de dados não comitados em outra sessão.... SE a
> > > > pessoa não conhece conceitos tão fundamentais e está desenvolvendo um
> > > > aplicativo com RDBMS, my god.....
> > > > > Bom, sobre o seu cenário de ter diversos arquivos de dados a
> > carregar em
> > > > paralelo (em SESSÔES diferentes no database) temos que :
> > > > >
> > > > > a. se existe INTEGRIDADE DE DADOS (por exemplo, constraints de PK/FK)
> > > > entre dados de diferentes arquivos, OU vc assegura que os arquivos com
> > as
> > > > PKs serão processados/inseridos primeiro, OU vc temporariamente
> > (durante a
> > > > carga) desliga as constraints e as religa no final da carga
> > (verificando os
> > > > dados antes, é claro) OU se viável usa delayed constraints
> > > > >
> > > > > b) se o problema é que a sessão x está carregando o arquivo 1 e nesse
> > > > momento entra uma sessão y que tenta carregar o mesmo arquivo, CLARO
> > que
> > > > para o database isso são sessões DIFERENTES : para vc controlar isso,
> > vc
> > > > TEM que colocar na procedure uma "inteligência" que registre que o
> > arquivo
> > > > está sendo processado, e portanto a sessão y TEM que "pular" ele - a
> > > > maneira COMUM no RDBMS Oracle é ter uma tabela de controle que vc locka
> > > > (LOCK é o meio de se assegurar acesso serializado, uma sessão por vez,
> > a um
> > > > dado recurso)...
> > > > > Poderia existir uma tabela LISTA_DE_ARQUIVOS, com uma coluna só
> > > > NOME_DO_ARQUIVO, e essa tabela ser carregada num pré-processamento com
> > a
> > > > lista toda dos arqs a carregar, aí a procedure teria uma lógica tipo :
> > > > >
> > > > > BEGIN
> > > > > for r in (select nome_do_arquivo from LISTA_DE_ARQUIVOS FOR UPDATE
> > SKIP
> > > > LOCKED) loop
> > > > > ...
> > > > > lê o arquivo registrado na coluna NOME_DO_ARQUIVO e faz os INSERTs
> > > > necessários
> > > > > ...
> > > > > delete from LISTA_DE_ARQUIVOS where current of;
> > > > > end loop;
> > > > > commit;
> > > > > END;
> > > > >
> > > > >
> > > > > okdoc ?? Aí se uma sessão y ser disparada enquanto uma sessão x está
> > > > lendo um dado arquivo 1, a linha correspondente à ele está LOCKADA e
> > > > portanto vai ser pulada e a sessão vai processar o arquivo 2....
> > > > >
> > > > > ==> é CLARO, eu estou supondo que o que vc quer é evitar que as
> > próximas
> > > > sessões processem o mesmo arquivo : não há necessidade, imagino, de
> > usar a
> > > > restrição mais rígida que vc cita (ie, PROIBIR as próximas sessões de
> > > > executarem enquanto a sessão x inicial tá rodando), MAS é plenamente
> > > > possível se fazer isso, aí vc usaria um LOCK TABLE numa tabela de
> > flag...
> > > > >
> > > > > []s
> > > > >
> > > > > Chiappa
> > > > >
> > > > > OBS : é claro, vc tem que ter CERTEZA que não há os mesmos dados,
> > com a
> > > > mesma chave, em arquivos diferentes : é ULULANTEMENTE óbvio e
> > conhecido que
> > > > se duas sessões fizerem simultaneamente INSERTs do mesmo dado com a
> > mesma
> > > > chave, em condições normais de uso (ie, constraints não-delayed, etc)
> > uma
> > > > delas (a segunda, normalmente) VAI ficar em WAIT, sim ??? E esse WAIT
> > só
> > > > será satisfeito quando a sessão original comitar, só então a
> > constraint vai
> > > > ser ativada e o registro é rejeitado com duplicated key....
> > > > >
> > > > > --- Em oracle_br@yahoogrupos.com.br, Carlos Silva <carlos-csilva@>
> > > > escreveu
> > > > > >
> > > > > > Ola pessoa!
> > > > > > Estou usando o oracle 10g ... Tenho uma procedure que recebi via
> > > > webservice arquivos, segundo informação de um rapaz que trabalha
> > comigo,
> > > > ele abre varias seções no oracle, e quando entra a primeira informação
> > já
> > > > entra a segunda, e essa segunda não consegue achar as informações da
> > > > primeira que nao foi processada ainda. Existe alguma forma de
> > controlar a
> > > > linha de chegada dessas informações. Tipo, enquanto nao foi dado
> > commit no
> > > > primeiro insert nao entrar nenhum registro na procedure ou insert.
> > > > > > At.:
> > > > > >
> > > > > > [As partes desta mensagem que não continham texto foram removidas]
> > > > > >
> > > > >****
> > > >
> > > > ****
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Fábio Prado
> > > www.fabioprado.net
> > > "Compartilhando conhecimentos e treinando profissionais em Bancos de
> > Dados
> > > Oracle"
> > >
> >
> >
> >
>
>
>
> --
> Fábio Prado
> www.fabioprado.net
> "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados
> Oracle"
>
