preciso executar um sql dinâmico mas o cliente prefere que não sej ausado o execute immediate tem outra forma de fazer? é preciso fazer uma deleção no sql dinâmico? usei o ref curso para outras consultas, mas para fazer o delete não sei como fazer... alguém tem alguma idéia???
abraços
Como não usaar execute immediate em sql Dinamico
-
- Rank: Programador Pleno
- Mensagens: 34
- Registrado em: Qua, 02 Set 2009 3:29 pm
- Localização: São José - SC
-
- Moderador
- Mensagens: 1177
- Registrado em: Qui, 15 Out 2009 10:28 am
- Localização: Recife
Para consultas tem o REFCURSOR e o EXECUTE IMMEDIATE para outras ações, desconheco outra forma para tratar dinamicamente....
-
- Moderador
- Mensagens: 1177
- Registrado em: Qui, 15 Out 2009 10:28 am
- Localização: Recife
Tem uma baita gambiarra que pode fazer
ativar o spool, fazendo com que o resultado de consultas sql fique no SPOOL gerando um arquivo .sql com as instrucoes das deleções.
ativar o spool, fazendo com que o resultado de consultas sql fique no SPOOL gerando um arquivo .sql com as instrucoes das deleções.
- fsitja
- Rank: OraSauro
- Mensagens: 611
- Registrado em: Seg, 19 Jan 2009 4:29 pm
- Localização: Gaúcho no Rio de Janeiro - RJ
"The scars exist to remind us that the past was real"
Campanha: Como fazer uma pergunta e obter uma resposta.
http://tkyte.blogspot.com/2005/06/how-t ... tions.html
OCA & OCP Developer — OCE SQL Expert — OCS Data Warehousing Specialist
Campanha: Como fazer uma pergunta e obter uma resposta.
http://tkyte.blogspot.com/2005/06/how-t ... tions.html
OCA & OCP Developer — OCE SQL Expert — OCS Data Warehousing Specialist
Para select dá para usar cursor variable (sys ref_cursor) mas para delete vai ter que ser no execute immediate mesmo.
O grande problema do delete com execute immediate é que você tem que fazer ele concatenando strings, e isso abre um buraco na segurança para vulnerabilidades de SQL injection, principalmente usando procedures, pois elas por padrão utilizam privilégios do OWNER da procedure (o usuário que acompilou), e que geralmente é superprivilegiado.
O jeito é validar TUDO o que é passado e concatenado para garantir que não há lixo ou um string mal-intencionado lá dentro. É uma coisa chata mesmo, ou usando vários IFs ou usando o auxílio da package DBMS_ASSERT.
Outra alternativa é, dependendo do que você quer fazer, usar invoker's rights, colocando a cláusula AUTHID CURRENT_USER na sua procedure. Isso vai garantir que o usuário rodando a procedure execute ela com seus próprios privilégios, mas às vezes você precisa usar definer's rights (comportamento padrão).
Dê uma olhada no link abaixo, onde o Tom Kyte explica como se defender contra SQL Injection. Como ele mesmo diz:
O grande problema do delete com execute immediate é que você tem que fazer ele concatenando strings, e isso abre um buraco na segurança para vulnerabilidades de SQL injection, principalmente usando procedures, pois elas por padrão utilizam privilégios do OWNER da procedure (o usuário que acompilou), e que geralmente é superprivilegiado.
O jeito é validar TUDO o que é passado e concatenado para garantir que não há lixo ou um string mal-intencionado lá dentro. É uma coisa chata mesmo, ou usando vários IFs ou usando o auxílio da package DBMS_ASSERT.
Outra alternativa é, dependendo do que você quer fazer, usar invoker's rights, colocando a cláusula AUTHID CURRENT_USER na sua procedure. Isso vai garantir que o usuário rodando a procedure execute ela com seus próprios privilégios, mas às vezes você precisa usar definer's rights (comportamento padrão).
Dê uma olhada no link abaixo, onde o Tom Kyte explica como se defender contra SQL Injection. Como ele mesmo diz:
http://asktom.oracle.com/pls/asktom/f?p ... 3706595353"It is not dynamic sql that is the issue. It is "the construction" of this sql that is the problem.
-
- Informação
-
Quem está online
Usuários navegando neste fórum: Nenhum usuário registrado e 2 visitantes