Deletar dados de tabela usando o sql

dependendo do banco é “delete from tabela”, sem o *

Ricardo já tentei sem o * e não funcionou

Qual erro está dando?

Tente

Statement stmt = con.createStatement(); stm.executeUpdate("delete from agenda");

só uma pequena dúvida…
qual a diferenca entre:

Statement stmt = con.createStatement();
stm.executeUpdate(“delete from agenda”);

e

Statement stmt = con.createStatement();
stm.execute(“delete from agenda”);

execute: serve para qualquer coisa (até procedures) e retorna um boolean
executeUpdate: para insert/update/delete e retorna um int
executeQuery: para selects e retorna um ResultSet

Porf favor,

Para fazer uma conexao com o BD da melhor maneira,
eu ultilizo ODBC, mas tenho que ficar abrindo a conexão
em toda a classe.Qual a melhor maneira de fazer uma conexão?
Oque significa Pool?

pool é um repositório de conexões, é onde as conexões ficam esperando até o momento de serem utilizadas. No pool as conexões ficam abertas, entao quando for utilizar a conexão é só pegar do pool e usar, nao vai levar o tempo de abrir a conexão pois ela já está la aberta....
Depois de utilizar a conexão ela volta para o pool...

a melhor maneira de abrir uma conexão depende de sua aplicação :wink:

public class ConnectionProvider
{
	private static Connection connection = null;

	private static Connection getConnection()
	{
		if (connection == null)
		{
			//open connection
		}
		return connection;
	}
	public static void closeConnection() throws SQLException{
		connection.close();
	}
}

"ricardolecheta":

public class ConnectionProvider
{
	private static Connection connection = null;

	private static Connection getConnection()
	{
		if (connection == null)
		{
			//open connection
		}
		return connection;
	}
	public static void closeConnection() throws SQLException{
		connection.close();
	}
}

O método getConnection() não deveria ser public? :?:

creio q sim, poi só assim terei acesso as instancias das conexões…

ops

Posso ser chato? O que esse closeConnection() acrescenta no teu codigo?

Se vc vai dar uma conexao pra quem pedir, e ele vai ter que chamar o closeConnection(), pq nao deixar que ele chame Connection.close() direto?

“cv”:

Posso ser chato? O que esse closeConnection() acrescenta no teu codigo?

Se vc vai dar uma conexao pra quem pedir, e ele vai ter que chamar o closeConnection(), pq nao deixar que ele chame Connection.close() direto? :)

cv, posso estar errado, mas… não é interessante deixar um método para fazer isso, pois vamos supor que mais para frente no desenvolvimento do sistema, antes de fechar a conexão, ele precisa fazer outras coisas, como por exemplo, gravar a hora que o usuário desconectou do sistema. Assim era só implementar dentro desse método, ou esse método chamar outro, e todas as classes que chamassem esse método não iriam mudar em nada.

E outra coisa.
o objeto connection está como private, então ele não pode dar um connection.close, mais ou menos um encapsulamento para esse objeto.

Hmm, o tipico caso do analista de sistemas que tem uma bola de cristal

Ao invés de prever o futuro desse jeito, não é mais fácil refatorar o código de uma vez, quando a necessidade de verdade chegar? Refatorar código é tão simples hoje em dia, po… no Eclipse, por exemplo, vc só tem o trabalho de buscar todas as referências a Connection.close() e alterá-las de acordo - e pode ter certeza, é mais fácil do que tentar prever todas as coisas que podem pedir pra vc fazer num sistema

“ManchesteR”:

E outra coisa.
o objeto connection está como private, então ele não pode dar um connection.close, mais ou menos um encapsulamento para esse objeto.

E desde quando a Connection está encapsulada, se vc retorna a mardita no getConnection()?

“cv”:

[
Hmm, o tipico caso do analista de sistemas que tem uma bola de cristal
…
e pode ter certeza, é mais fácil do que tentar prever todas as coisas que podem pedir pra vc fazer num sistema
…

Eu ja diria que depende. Alguem vai ler isso, interpretar ao pe-da-letra e nao se preocupar com o “futuro” na hora, pois “sempre da pra refatorar”… ou seja, o cara vai passar mais tempo reescrevendo o codigo do que se tivesse feito ( quase ) certo de cara.

Claro que querer prever tudo de cara no sistema nao rola, mas se apoiar em refatoracao como desculpa pra tudo tmb nao da. Se voce sabe que algo vai ser necessario em algum ponto, pra que deixar pra fazer mais tarde?

Rafael

Se voce sabe que algo vai ser necessario, entao esta num testcase. E, se esta num testcase, voce vai ter que implementar agora, pq vc precisa daquela funcionalidade agora, ou o seu teste nao passa e vc nao vai pra proxima funcionalidade. Simples, Rafael… nao tem pra que complicar nisso

Nao necessariamente. Pessoalmente prefiro fazer tudo o que sei que vai ser necessario de cara, ao inves de esperar o momento chegar. Eh questao de gosto, de preferencia de desenvolvimento, e, ao meu ver, nao ha razao para querer fazer com que as outras pessoas se adaptem a uma maneira de desenvolvimento de sua preferencia simplesmente pelo fato de ser… de sua preferencia.

Se o ponto for "… vou colocar isso pq talvez precise em algum momento… ", entao que soh implemente quando precisar mesmo.

Rafael

De acordo… mas tome cuidado com o tamanho que vc da pra os talvezes e pras certezas. Se todo mundo tivesse certeza de que pra fazer uma aplicacaozinha de negocios precisava de um banco de dados, o Prevayler nao existiria hoje - acho que vc consegue imaginar o dialogo:

• Ei, precisamos fazer um controle de estoque.
• Legal, como funciona o seu estoque?

<explicacao sobre o negocio>

• Bacana. Acho que ja da pra comecar a rabiscar como o sistema vai se parecer.
• Legal, que banco e dados voces vao usar?
• Hmm… banco de dados? Pra que vc precisa de um?
• Pra guardar os dados, ue!
• Sim, mas pelo que vc me explicou, nao tem tantos dados assim a se guardar. Tem certeza que vc vai querer gastar recursos com um banco de dados?
• Ue, que alternativa tem, entao?
• Hmm, a gente podia guardar tudo em arquivos, no disco… mas isso iria tornar a geracao de relatorios muito dificil, entao…
• So nao me diga que vc quer guardar as coisas na RAM agora…
• Hmm, epa, perae… EEEEEEEEEEEEI!