Minha aplicação possui um botão para executar um JFileChooser(). Consigo localizar o arquivo desejado, capturar o .getSelectedPath() e jogar dentro de uma JTextField().
Em seguida, tenho outro botão para CONFIRMAR a restauração das tabelas do MySQL. Nele, tenho este código:
privatevoidrestauraBackup(StringfileSQL){//receboocaminhocorretoporparâmetroapósexecutaroTRUNCATE//dastabelasantigas.Funcionandoperfeitamente.
fileSQL=fileSQL.replace("\\","/");if(fileSQL==null){
msg.aviso("Localize um arquivo SQL para executar a restauração.");}else{
StringrestoreCmd="mysql.exe -uroot -proot dadostemporarios < "+fileSQL;try{
Processprocess=null;process=Runtime.getRuntime().exec(restoreCmd);intprocessCom=process.waitFor();if(processCom==0){
msg.sucesso("Restauração concluída com êxito.");}else{
msg.falha("Falha na restauração do arquivo SQL.");}
}catch(IOException|InterruptedExceptione){
e.printStackTrace();}
}
}
Neste momento a aplicação trava e no Gerenciador de Tarefas, a aplicação cria o processo do mysql.exe mas não executa nada. O que estou fazendo de errado?
@Jonathan_Medeiros Obrigado pela ajuda… Infelizmente também não deu certo. A Aplicação continua travada, com um subprocesso do mysql.exe ativo. Quando finalizo apenas o subprocesso, a aplicação exibe a mensagem de SUCESSO no procedimento porém, no BD, nada aconteceu.
O mysql.exe aparece junto com o Host de Console quando clico no botão RestaurarBackup.
S
staroski
Quando você utiliza a classe Runtime para executar um programa externo que espera parâmetros, você precisa utilizar o método exec que recebe um array de String.
O primeiro elemento do array tem que ser o programa em si e cada elemento seguinte tem que ser um parâmetro.
Olá @staroski… Obrigado por ajudar. O Código em si não deu erro nem lançou Exception com o try / catch porém, a aplicação se manteve travada. Do mesmo jeito… Tentei dar um sout no processCom antes de entrar no IF mas ele travou antes.
F
fabioklopes
Pessoal, percebi que mudando o arquivo SQL para a o diretório padrão do JFileChooser() [C:\Users\fulano\arquivo.sql] o procedimento funciona. Logo imaginei: “então deve ser permissão de acesso no diretório oficial. Onde o arquivo NECESSITA estar”. Resumindo: por conta de padronização da aplicação eu não posso mudar o diretório do arquivo SQL.
Apliquei o famoso 777 no Ruindows para o usuário Todos (Everyone);
A aplicação não travou mais porém, ainda aparece a mensagem de erro na importação do SQL;
Quando vou no diretório padrão do JFileChooser() e faço a importação do arquivo copiado, tudo flui perfeitamente até a mensagem final de sucesso aparecer;
O arquivo.sql precisa estar obrigatoriamente no drive W:/backup-anual/arquivo.sql.
Será que ainda devo configurar alguma coisa no JFileChooser() ???
F
Solucao aceita
fabioklopes
Pessoal… Consegui resolver. Finalmente… Uma coisinha boba que só percebi na hora de tentar executar a importação via DOS.
O código final ficou assim:
privatevoidrestauraBackup(StringfileSQL){fileSQL=fileSQL.replace("\\","/");if(fileSQL==null){msg.aviso("Localize um arquivo SQL para executar a restauração.");}else{StringlinhaCmd="cmd /c mysql.exe -uroot -proot dadostemporarios < \"" + fileSQL + "\"";try{//PROCESScomoensinadopelo@staroski.VALEU!Processprocess=Runtime.getRuntime().exec(linhaCmd);intprocessCom=process.waitFor();if(processCom==0){msg.sucesso("Restauração concluída com êxito.");}else{msg.falha("Falha na restauração do arquivo SQL.");}}catch(InterruptedException|IOExceptione){msg.falha("Falha de exceção na tentativa te restaurar o backup.");}}}
A solução para forçar a importação funcionar, não era no JFileChooser() mas sim na linha de instrução DOS que eu estava passando. Se fizer manualmente no terminal de comandos, a linha deveria conter ASPAS para especificar a localização do arquivo SQL. Assim:
