Smalldatetime y Datetime

"Manolo Zepeda" escribió en el
mensaje news:

Que tal Gustavo.
Estoy checando y el problema lo tengo en .NET,necesito enviarle los
parametros de la forma 20081024, ya puse en el Store SET DATEFORMAT YMD y
sigue sin funcionar solo en las fechas que tienen la hora guardada, en las
que aparecen como 24/oct/2008 12:00:00 a.m. funciona sin problema.

Hola, Manolo:

Los valores DATETIME y SMALLDATETIME almacenan, como su nombre lo indica,
coordenadas temporales (la posición de un evento en la línea del tiempo).

Entre el momento en que una coordenada temporal deja de llamarse "25 de
octubre" y cuando comienza a llamarse "26 de octubre" transcurren 24 horas.

Una fecha representada con el formato habitual '20081024' representa el
instante exacto en que comienza el 24 de octubre, es deir, las 0 horas del
24 de octubre. Y por supuesto, no representa la coordenada de un evento
ocurrido un segundo despues. Dicho en cristiano: no es lo mismo decir "24 de
octubre de 2008" que "cero horas, cero minutos, un segundo despues del
inicio del 24 de octubre del 2008" (en ese tiempo el Gran Colisionador de
Hadrones podría devorar el planeta).

Cuando dejas que SQL Server registre automáticamente el momento en que se
registra un evento, lo haces asignando la funcion GETDATE() al valor por
omisión de la columna correspondiente. Y GETDATE() toma la coordenada
completa.

Tienes varias opciones (y casi todas te las han sugerido, pero todos tenemos
nuestros días de espesura):

1.- Tomar en cuenta, en tus consultas, que las columnas registran la
coordenada completa y en vez de escribir:
BETWEEN @FechaInicial AND @FechaFinal
escribir
BETWEEN @FechaInicial AND DATEADD(d, 1, @FechaFinal)
esto tiene dos inconvenientes: el primero es que si por mala suerte se
registra un evento EXACTAMENTE a la 0 horas de @FechaFinal, aparecerá dos
veces. El segundo -me pasó hace unos días- es que si "esta tabla" se combina
en una vista con otra tabla equivalente en la que las fechas no incluyan la
hora, el uso de este criterio sobre la vista hará aparecer en la consulta de
un día todas las transacciones de la segunda tabla registradas al día
siguiente.

Ambos pueden resolverse mediante un filtro un poco más complicado:
BETWEEN @FechaInicial AND
DATEADD(ms, 999,
DATEADD(s, 59,
DATEADD(m, 59,
DATEADD(h, 23, @FechaFinal))))
Como ves, es un asco.

2.- La segunda es crear un trigger "FOR INSERT" sobre la tabla. Asumiendo
que la tabla tiene una clave primaria, puedes usar una función del tipo de
esta

CREATE FUNCTION FechaEntera( @inFecha SMALLDATETIME)
RETURNS SMALLDATETIME AS
BEGIN
RETURN CONVERT(DATETIME,
FLOOR(CONVERT(FLOAT,@inFecha)))
END

y usarla dentro de un trigger como éste:

CREATE TRIGGER AjustarFecha ON TU_TABLA
FOR INSERT
AS
UPDATE TU_TABLA SET TU_TABLA.fecha dbo.FechaEntera(GETDATE())
FROM INSERTED
WHERE INSERTED.id = TU_TABLA.id

No es que sea bonito (una característica de SQL es que hagas lo que hagas,
siempre hay a quien no le guste la solución), pero permite que las fechas se
registren como esperas sin necesidad de establecer valores por omisión
(debes permitir el uso de NULL en la columna que almacena la fecha, de lo
contrario el INSERT fallará -creo).

Por supuesto, esto funcionará si tu tabla tiene una clave primaria, o al
menos un conjunto de columnas que produzcan una combinación unica para cada
fila (de lo contrario, la tabla estaría mal diseñada, pero nunca está de más
recalcar este punto).

3.- Especificar la fecha desde tu aplicación con la precisión con la que tu
aplicación la necesita. Prefiero la segunda opción, aunque si algún día te
toca migrar la aplicacion a uno de esos esperpentos que no admiten triggers,
vas a tener problemas, de modo que siempre es conveniente que las
aplicaciones se aseguren de hacer lo que ellas necesitan que se haga.


Salud!

Manolo Zepeda,

Si usas un procedimiento macenado y nada mas te interesa filtrar por el
valor de la fecha, entonces puedes truncar el tiempo en la aplicacion cliente
o en el procedimiento.

Ejemplo:

create procedure dbo.usp_p1
@sd datetime,
@ed datetime
as
set nocount on

select
c1, c2, c3, c4, c5
from
dbo.mi_tabla
where
columna_fecha >= dateadd(day, datediff(day, '19000101', @sd), '19000101')
and columna_fecha < dateadd(day, datediff(day, '19000101', @ed) + 1,
'19000101')
go


AMB


"Manolo Zepeda" wrote:

Que tal Carlos.
Estoy checando y el problema lo tengo en .NET

Asi como lo indicas esta bien, si me sale la consulta, pero necesito enviar
las fechas en ese formato, ya puse en el Store SET DATEFORMAT YMD y sigue sin
funcionar, solo en las fechas que tienen la hora guardada, en las que
aparecen como 24/oct/2008 12:00:00 a.m. funciona sin problema.

Saludos

"Leonardo Azpurua" <l e o n a r d o [arroba] m v p s [punto] o r g> escribió
en el mensaje news:

Ambos pueden resolverse mediante un filtro un poco más complicado:
BETWEEN @FechaInicial AND
DATEADD(ms, 999,
DATEADD(s, 59,
DATEADD(m, 59,
DATEADD(h, 23, @FechaFinal))))
Como ves, es un asco.

Como dije, todos tenemos nuestros "momentos espesos".

Un poco menos asqueroso sería:

BETWEEN @FechaInicial AND
DATEADD(ms, -1,
DATEADD(d, 1, @FechaFinal))

es edcir, un milisegundo antes del día siguiente, y ahi entran todas las
transacciones del último día, pero de ninguna manera la primera del día
siguiente.


Salud!

Leonardo,

Ese metodo tiene sus implicaciones, al menos si usas tipo datetime y la
columna no solamente contiene la parte fecha, puesto que este tipo de data
tiene una exactitud de 3.3 milesimas de segundo, por lo que el valor
'2008-10-24T23:59:59.999' es interpretado como '20081025'.

SELECT DATEADD(millisecond, -1, '20081025')
GO

SELECT DATEADD(millisecond, -2, '20081025')
GO

Por eso se recomienda usar "col_fecha >= @fecha_inicio and col_fecha <
@fecha_final + 1"

Donde el resultado de (@fecha_final + 1) debe tener como tiempo las
00:00:00.000


AMB


"Leonardo Azpurua" wrote:

"Leonardo Azpurua" <l e o n a r d o [arroba] m v p s [punto] o r g> escribió
en el mensaje news:
> Ambos pueden resolverse mediante un filtro un poco más complicado:
> BETWEEN @FechaInicial AND
> DATEADD(ms, 999,
> DATEADD(s, 59,
> DATEADD(m, 59,
> DATEADD(h, 23, @FechaFinal))))
> Como ves, es un asco.


Como dije, todos tenemos nuestros "momentos espesos".

Un poco menos asqueroso sería:

BETWEEN @FechaInicial AND
DATEADD(ms, -1,
DATEADD(d, 1, @FechaFinal))

es edcir, un milisegundo antes del día siguiente, y ahi entran todas las
transacciones del último día, pero de ninguna manera la primera del día
siguiente.


Salud!

Que tal Alejandro.
Muchas gracias por tu aportación, voy a tomar en cuenta todas las opiniones
que me han hecho,no pense que fuera tan complicado trabajar con fechas.
Otra cuestion que quiero comentar es si me afecta que ponga en la consulta
de esta manera para el filtro de la fecha, ya que de esta manera si me
arroja las fechas sin el tiempo, pero no se el rendimiento que ocasione.
CONVERT(nvarchar(11), FechaVenta) BETWEEN @Fecha1 AND @Fecha2
Fecha1 y Fecha2 (vienen con formato de un #10-24-08#) desde punto Net y asi
si puedo ver las fechas sin la hora.

Saludos y gracias de nuevo.