Amigos,
estou desenvolvendo um aplicação que acessa banco Oracle. Esta aplicação terá um módulo de alteração de senha. Como faço para alterar uma senha de um usuário do banco através de uma aplicação java sem chamar uma procedure?
Obrigado.
Marcelo.
E pq não usar Stored Procedure? Acho que seria o modo mais fácil…
Bom, tu pode tentar algumas gambiarras… :-]
Através da classe Runtime é possível executar comandos de shell, mesmo que estes esperem input do usuário…
Por exemplo, o comando abaixo (UNIX, não sei se rola no windows) faz um ftp e pega um arquivo:
ftp -vn <<-EOF
open localhost
user geovani minhasenha
bin
get arquivo.tar.gz
quit
EOF
Talvez seja possível fazer o mesmo com os programas de admin do oracle…
Boa sorte!
O Oracle guarda as senhas dos usuários em uma tabela. Não lembro o nome dela agora, mas você pode dar uma procurada nisso e em quais são os campos.
Aí basta mandar um UPDATE TABELA SET CAMPOSENHA=´NovaSenha´ WHERE CAMPOID=´Id´.
Mas acho que você precitar ter logado no banco como administrador para fazer isso.
Colegas,
Vamos esclarecer alguns pontos básicos aqui, principalmente
no que se diz respeito aos processos de gerenciamento e autenticação
de usuários pelo Oracle Database.
Primeiramente queria colocar aqui que o nosso amigo Bani, o Moderador,
não está correto em sua afirmação. O processo de gerenciamento de usuários
e senhas pelo Oracle é um pouquinho mais complexo para ser resolvido por
um simples update na tabela DBA_USERS do banco de dados.
No banco, não só o usuário e sua senha, mas todas as informações relevantes
ao banco, e o seu dicionário de dados é armazenado na forma de tabelas sob
propriedade de dois usuários (SYS e SYSTEM).
Tomemos como exemplo a seguinte situação:
1 - Criaremos um usuário chamado java01 com a senha portal_java
2 - Criaremos um usuário chamado java02 com a senha portal_java
CREATE USER java_01 IDENTIFIED BY portal_java DEFAULT TABLESPACE teste;
CREATE USER java_02 IDENTIFIED BY portal_java DEFAULT TABLESPACE teste;
Agora vamos selecionar o conteúdo da tabela DBA_USERS
USERNAME USER_ID PASSWORD
------------------------------ ---------- ------------------------------
SYS 0 70C70B7D549063F2
SYSTEM 5 92CF1A8F05375C00
OUTLN 11 4A3BA55E08595C81
DBSNMP 17 E066D214D5421CCC
ORDSYS 20 7EFA02EC7EA6B86F
ORDPLUGINS 21 88A2B2C183431F00
MDSYS 22 72979A94BAD2AF80
LBACSYS 23 AC9700FD3F1410EB
JAVA_01 16 8F2601BCC81B9796
JAVA_02 8 A2A3C29C83C02265
Pela listagem acima, podemos observar que mesmo que você digite duas
senhas iguais para usuários diferentes o banco de dados irá fazer a
criptografia dessas senhas e será gerado uma "String" diferente para
cada usuário criado no banco de dados.
Esse é o seu primeiro problema e é a demonstração cabal por que a opnião
do colega Bani não dará certo.
Nunca testei isso, pois nunca houve necessidade específica, diferentemente
do seu caso mas acho que você pode tentar fazer o seguinte:
Tentar fazer isto via PreparedStatment, como se fosse um insert, update ou
delete comum. Lembre-se que INSERT,UPDATE e DELETE são instruções DML e o
CREATE USER, ALTER USER, e os demais da vida são DDL. Efetivamente não sei
se o PreparedStatement executa DDL.
Caso o passo acima de pau, não vejo outra saída senão você utilizar procedures
com sql dinâmico.
Pq mesmo vc não quer usar procedures?
A instrução abaixo altera a senha do usuário java_01
ALTER USER java_01 IDENTIFIED BY portal DEFAULT TABLESPACE teste;
Essa instrução irá trocar a senha do seu usuário java_01
Maiores informações podem ser obtidas em http://tahiti.oracle.com
Qualquer dúvida estou a disposição.
Eu gostaria que a aplicação fosse o mais independente possível do banco de dados.
Verifiquei o uso de PreparedStatement na API e parece que vai funcionar, pelo menos ela diz que comandos DDL podem ser executados através do executeUpdate().
Obrigado a todos pelas dicas.
Esse negócio da aplicação ser totalmente independente do servidor de banco de dados é um ponto interessante, pois dependendo da aplicação, do escopo dela é claro e do servidor de banco de dados que se está utilizando, têm-se que ter uma preocupação toda especial, no que se diz respeito a performance e tudo mais.
Outra coisa importante é que vários distribuídores de banco de dados tem parâmetros diferentes para codificações de funções SQL que fazem determinado trabalho.
Já que você viu que funciona, por PreparedStatement acho legal ser feito por aí, mas não vejo problema nenhum em utilizar stored procedure com o intuito de ser "independente" do servidor de banco de dados, pois na grande maioria dos casos os servidores de bd hoje em dia suportam stored procedures e afins…o que eventualmente mudaria seria a forma de se escrever esta stored procedure se você em um futuro fosse migrar do Oracle para o SYBASE (exemplo)…
Também concordo que é importante não atrelar a aplicação ao banco de dados, mas nesse caso, se tu usar executeUpdate pra executar comandos DDL, isso estará acontecendo, pois quando outro banco for usado, o comando DDL será diferente.
Acho que nesse caso fica mais encapsulado usar procedure, já que quando o banco for trocado, bastará criar uma procedure com o mesmo nome… E banco de dados sem suporte a procedures é f…! Até banco de dados grátis, como o firebird (variação opensource do interbase), suporta.