Problema con sentencia sql en java

[lordphoenixs]

Hola. tengo la siguiente sentencia

Código:

UPDATE Internacion SET FecAlta = '08/07/2010' WHERE IdInternacion = id

El problema que en vez de actualizar 08/07/2010 me actualiza de la siguiente forma 07/08/2010.
Sin embargo al momento de insertar fechas el sistema inserta sin ningun problema con el formato dd/mm/yyyy.

Alguien sabe como puedo solucionar el tema del update?????

[lordphoenixs]

Bueno descubri parte de mi problema.

utilizo esto para convertir a date del sql

Código:

public static java.sql.Date(java.util.Date dia){
return new java.sql.Date(dia.getTime())
}

Esto pedaso de codigo devuelve de la siguiente forma la fecha

2010/08/07 y lo inserta de esta forma en la BD 07/08/2010 en vez del siguiente formato que es el que yo quiero 08/07/2010

si alguein me dise como solucionarlo se lo agradeceria muchisimo.

[Fuzzylog]

xD yo utilizo to_date('08/07/2010' ,'dd/MM/yyyy') en la SQL y lo añade correctamente.

[GreenEyed]

Más que insertarlo en la BDD, el problema es cómo quieres visualizarlo. Si el formato de visualización de SQL que tienes es MM/dd/yyyy pues lo metas como lo metas te lo sacará de esa forma.
Lo que tienes que definir es en que formato lo introduces y en que formato lo sacas. La parte de introducir ya te la hace el solito si usas java.sql.Date. Así que usa algo como lo que menciona FuzzyLog para controlar en que formato lo sacas... o sacalo con java.sqlDate tambien y luego lo formateas en Java como quieras.

S!

[elAntonie]

Wenas

Yo pienso que las fechas deben insertarse siempre enteritas.

Entendiendo como enteritas, fecha y hora.

La razon, que a menos que se vea de primeras que no necesitaras la hora para nada, es que siempre te puede ser util. Por ejemplo para efectuar una ordenacion de una tabla de acciones por la fecha. Si tienes la hora se hara siempre bien.

Luego las muestras en el formato que te de la gana.

Saludos.

[Denis127]

Cuando sacas un dato de tipo date de la base de datos, el resultado es un Timestamp de la libreria java.sql.

Lo correcto sería que siempre conserves ese objeto, pero que a partir de el obtengas los datos que necesites. ya que a la hora de insertarlo en la base de datos no te dará problemas insertar Timestamps.

[GreenEyed]

Yo pienso que las fechas hay que guardarlas como las necesites. Si sólo necesitas el día, pues sólo el día por que si no te pueden ocurrir casos curiosos como que al comparar dos fechas te de distinto por que el día es el mismo pero la hora es diferente, y tu sólo querías comparar el día.

Y el resultado de un campo de tipo date en la BDD no es siempre un Timestamp. En Oracle, por ejemplo, a partir de ciertas versiones diferencia explicitamente entre las columnas de tipo Date y las de tipo Timestamp, y si usas el tipo Date solo te almacena el día, sin hora concreta. Así que al sacarlo lo adecuado es un java.sql.Date.

El problema es la confusión que hay en todo esto por los nombres de los tipos de las columnas, dos tipos Date que significan cosas diferentes, diferentes versiones de BDD se comportan diferente... en fin, un lío.

S!

[elAntonie]

Iniciado por GreenEyed

Yo pienso que las fechas hay que guardarlas como las necesites. Si sólo necesitas el día, pues sólo el día por que si no te pueden ocurrir casos curiosos como que al comparar dos fechas te de distinto por que el día es el mismo pero la hora es diferente, y tu sólo querías comparar el día.

Pues comparas solo el dia. Donde esta el problema??

Iniciado por GreenEyed

El problema es la confusión que hay en todo esto por los nombres de los tipos de las columnas, dos tipos Date que significan cosas diferentes, diferentes versiones de BDD se comportan diferente... en fin, un lío.

Ahi si te doy la razon.

Saludos.

[GreenEyed]

Iniciado por elAntonie

Pues comparas solo el dia. Donde esta el problema??

El problema está en que si tu solo necesitas días y tratas días... ¿por que compararlos no da un resultado coherente a no ser que explicitamente le digas que tiene que comparar el día?

No es que no se pueda solucionar, es que no hay por qué almacenar la fecha y la hora si no te sirven para nada y te ahorras tener que hacer cosas de estas.

Es como usar floats para guardar enteros... por si acaso.

Repito, si no la necesitas para nada. El ejemplo que pones tú no es válido por que si necesitas ordenar las acciones a ese nivel entonces necesitas guardar la hora. Pero por ejemplo, guardar la hora en las fechas de nacimiento introducidas por el usuario no tiene ningún sentido, especialmente por que el usuario no te la introducirá y para guardar la hora te la estarás inventando.

S!

[elAntonie]

Que siiiiiiiiiiiiiiii, que tienes razoooooooon.

Pero te comento algo que me he encontrado varias veces. Los famosos 'no es necesario guardar la hora' y luego el cliente no puede ordenar adecuadamente porque hay fechas 'en el mismo dia'.

aunque es cierto que eso es para despedir al analista.

Saludos.

[GreenEyed]

Bueno, sí, eso es cuestión del análisis, que hay cada uno...

Esos son de los que hacen literalmente lo que dice el cliente y como "dice que no necesita la hora...".

Eso y el hacer toooooodos los campos obligatorios por que "los queremos todos", lo de "esto siempre se hace así" o "no esto nunca ocurre" son como un test para analistas.

La cuestión es que de los buenos hay muy pocos, es más fácil pegarse con ordenadores que con gente y sus manías .

[lordphoenixs]

Bueno. Primero que todo les comento. Anoche era las 1 de la madrugada cunaod lo solucione. La BD esta bien y trabaja en español, lo que significa que el formato d einsercion es dd/MM/yyyy. Ahora les voy a poner la solucion. Bendito sea el Net Beans.

java trabaja por defecto el standar ANSI de fecha yyyy/MM/dd. Por lo tanto, para solucionar mi problema de insercion necesitaba sobreescribir uno de los metodos de la funcion Date() a fin de solucionar el problema.

Aca les dejo el link
http://download.oracle.com/docs/cd/E...toString%28%29

y aca les pongo el codigo que hice anoche.

Código:

import java.sql.Date;

public class mi extends Date {

	public mi(long date) {
		super(date);
	}


	public String toString() {
		int year = super.getYear() + 1900;
		int month = super.getMonth() + 1;
		int day = super.getDate();
		
		char buf[] = "2000-00-00".toCharArray();
        buf[0] = Character.forDigit(year/1000,10);
        buf[1] = Character.forDigit((year/100)%10,10);
        buf[2] = Character.forDigit((year/10)%10,10);
        buf[3] = Character.forDigit(year%10,10);
        buf[5] = Character.forDigit(day/10,10);
        buf[6] = Character.forDigit(day%10,10);
        buf[8] = Character.forDigit(month/10,10);
        buf[9] = Character.forDigit(month%10,10);
		
	return new String(buf);
	}
	
	

}

Si alguno quiere ver bien el codigo. Pues ingresen a NetBeans que alli pueden ver como esta escrito.

y Bueno ya pueden cerrarlo al hilo

[GreenEyed]

Por dejarlo claro si alguien encuentra este hilo en el futuro, simplemente precisar dos cosas:

.- java.sql.Date por defecto lee y escribe fechas en formato "yyyy-mm-dd", pero java.util.Date escribe por defecto en formato "dow mon dd hh:mm:ss zzz yyyy" y no se recomienda crear java.util.Date directamente a partir de String.

.- Para convertir entre cadenas y fechas, lo mejor es utilizar alguna subclase de java.text.DateFormat y más en concreto java.text.SimpleDateFormat en la mayoría de casos.

No es que el metodo que pongas esté mal, pero es que usa metodos "deprecated" que puede que algún día desaparezcan y no se garantiza su funcionamiento en todos los casos.

S!

[elAntonie]

Tambien, indicar que existe otro modo de conversion en java.

Joda Time

http://www.adictosaltrabajo.com/tuto...uccionJodaTime

Saludos.