consuta de fechas porque no funciona???

[jpalbox]

Hola estoy haciendo una consulta con fechas. Tengo la fecha que quiero comparar en una variable y el otro campo es un campo de la base de datos en formato fecha pero hago la consulta y no sale ningun registro cuando si tengo registros q cumplan esa condicion

hoy=11&"/"&08 &"/"& 2002
...
....
sql = "SELECT * FROM reservas r1, horares r2 WHERE R1.HORA=R2.ID and r1.fecha = #"&hoy&"#"
Set result = con.Execute(sql)
;)

[urjose]

hoy=11&"/"&08 &"/"& 2002

¿?¿?¿?

hoy=date

estas concatenando mal pues que 11, 08 y 2002 son numeros deberian de estar dentro de la cadena,

hoy="11/08/2002"

Saludos

<center>
<a href=http://comunidadguru.com><img border=0 src=http://comunidadguru.com/imagenes/logos/logo.gif></a>
</center>

[jpalbox]

He corregido la fecha pero el problema sigue, es decir la consulta no muestra ningun registro cuando en verdad si hay registros con esa fecha ;)

[jpalbox]

Una ayuda por fa. Porque no funciona la consulta con la fecha??

[jasistemas]

jejeje... el eterno problema con las fechas... esto te va a salir en un buen billete!!!..

Bueno, prueba esto:
arma tu cadena de fecha como: MM/DD/AAA
y luego en la cadena SQL compara tu campo fecha de la bd contra esa fecha y veras que te funciona..

Tambien checa que en access tu campo fecha tenga el formato fecha corta..., como luego podras comprobar mediante las consultas de access, para poder enviar una cadena de consulta con fecha SIEMPRE tienes que ponder el formato EU es decir MM/DD/AAAA, independientemente del formato de tu sistema operativo... por que?, sepa... pero, no me creas: prueba por ejemplo estas 2 consultas DENTRO DEL SQL.

Select * from tabla where fecha = &quot;06/08/2002&quot;

Select * from tabla where fecha = &quot;26/08/2002&quot;

Si las ejecutas.. ambas te retornaran datos

Ambas guardalas... y al volver a abrirlas veras que Access te cambio la consulta como:

Select * from tabla where fecha = &quot;08/26/2002&quot;

Pero solo EN LA SEGUNDA CONSULTA!!!!.. claro, no sabia que la primera tambien era d/m/a... algo peor pasa si se trata de un &quot;INSERT&quot;... ya que en el primer caso, en lugar de grabar &quot;6 de agosto&quot;, esta grabando &quot;8 de junio&quot;..


ASi que ojo con esto, finalizando tu cadena debe ser:
select * from tabla where fecha = &quot;mm/dd/aaaa&quot;

Saludos
Juan Arturo

[jpalbox]

Creo q te entendi. y esta fucionando ya la consulta. Muchas gracias amigo.

Pero vamos a ver si me aclaro.

Entonces pa q te sirve seleccionar cuando creas la base de datos el formato fecha dd/mm/aaaa si luego el ordenador toma el formato mm/dd/aaaa. Y ademas esta configurado en el panel del control del ordenador el formato dd/mm/aaaa.?
Siempre toma el formato usa?
gracias ;)

[MariHo]

Por eso yo ya aprendí la lección, siempre utilizo mejor las fechas con INT y no hay problema.

POr ejemplo hoy es:

20020812


Es fácil ordenar, buscar rangos y hacer lo que se pegue en gana.


un saludo

MariHo
;¬)

[AlZuwaga]

Exacto, el formato numérico AAAAMMDD es lo mejor que hay (hasta puede estar almacenado en un campo tipo texto... así lo uso yo y no me da problemas)

[jasistemas]

Pero si usas ese formato podrias ocasionar que se vayan datos invalidos en tus tablas, ademas no podrias hacer calculos con fechas, a menos que siempre las conviertas primero a tipo Date.... es mejor entender como funciona (no el porque porq eso ni Bill lo sabe), veran que luego luego se acostumbraran.

[jasistemas]

Ademas, seria una lata querer hacer un group by por mes o año, ya que habria que hacerles el substring... en vez de eso:
select year(campofecha), month(campofecha) from tabla group by year(campofecha), month(campofecha) y algunas otras minucias.

[MariHo]

Pues yo he tenido que migrar mis datos de ACCESS a MySQL y de MySQL a SQL Server, en servidores Unix, Windows NT, Windows 2000, en España y Estados Unidos, creanme que si hubiese utilizado el tipo de campo date habría tenido muchos problemas en las migraciones y con el código, un servidor español Unix que tiene la fecha en formato español con base de datos MySQL es bastante diferente de un servidor norteamericano con Windows 2000, SQL Server como servidor de base de datos y formato de fecha anglosajón, de eso no me cabe la menor duda.

Es cierto que para agrupar datos es puede resultar un poco más complicado pero no tanto, estamos trabajando con números al fin y el cabo, podemos darle el formato que queramos sin utilzar más que dos o máximo tres funciones del ASP.

Por cierto dazuaga, creo que utilizar campo de tipo INT es un poco más eficiente que un tipo de campo TEXT o similar.

A jasistemas le puedo decir que un group con INT es mucho más eficiente que uno con date, además estamos utilizando igualmente una sola función del SQL, LEFT(20020202, 3) así que el trabajo es el mismo.

Como dices tu, es cuestión de entender cada uno la forma en que trabajamos, yo por mi experiencia de comunicar diferentes bases de datos y de la diferencias que existen entre sistemas de bases de datos, sistemas operativos, configuraciones regionales, etc, recomiendo trabajar con la forma que expuse. En más sencillo tener un código estándar que funcione bien con cualquier cosa.

un saludo

MariHo
;¬)

[AlZuwaga]

que buen tema este... las fechas son realmente un quilombo en ASP :-p

En más sencillo tener un código estándar que funcione bien con cualquier cosa.

definitivamente

Por cierto dazuaga, creo que utilizar campo de tipo INT es un poco más eficiente que un tipo de campo TEXT o similar

Puede que lo sea... desconozco las cuestiones de la eficiencia, pero en definitiva es lo mismo para ASP ya que se trata como un Variant

[MariHo]

Pero no sé porque algo me dice adentro que en la base de datos (ACCESS, SQL, MySQL) una consulta es más rápida con INT, más cuando utilizamos funciones.




MariHo
;¬)