¿Que sera mejor?, WHERE

Hola, la segunda opcion es mas eficiente, cuando vos aplicas una funcion a
la izquierda del where esto hara que no se usen los indices de forma
eficiente


Saludos

[Microsoft MVP SQL Server]
www.sqlgurus.org
Buenos Aires - Argentina
http://maxiaccotto.blogspot.com/
"Isaias" wrote in message
news:

Estoy metido en una duda, ¿Que sera mejor o mas eficiente?

1..
SELECT *
FROM MyTabla
WHERE datediff(dd,MyColFecha,getdate()) > 180

2..
DECLARE @MyFecha datetime
SET @MyFecha = DATEADD(day, -180, getdate())

SELECT *
FROM MyTabla
WHERE MyColFecha <= @MyFecha

Saludos
IIslas

Isaias,

Todavia falta informacion para darte una respuesta total.

1- Como ya indico Maxi, no se recomienda manipular las columnas en las
expresiones de un JOIN on de la clausula WHERE, porque entonces SQL Server no
considera esa expresion como una expresion de busqueda y no intentara hacer
un analisis de los indices de la tabla para resolver esa busqueda.

2 - La segunda forma te dara un probabilidad mayor de que algun indice pueda
ser usado, pero al usar una variable intermedia, SQL Server no hara uso del
histograma de distribucion de valores en la llave del indice adecuado y usara
la densidad de las columnas que participan en esa expresion y que forman
parte de la llave del indice, para determinar laoperacion que se llevara a
cabo sobre ese indice (plan de ejecucion). SQL Server usa los valores que son
conocidos en tiempo de compilacion, por lo que cualquier referencia a una
variable intermedia no sera usada para analizar el histograma de distribucion
de valores. Si vas a usar esa sentencia en un procedimiento almacenado,
entonces usa el parametro en la expresion de la clausula WHERE directamente.

Ejemplo:

create procedure dbo.p1
as
set nocount on

select c1, c2, cn
from dbo.t1
where fecha <= DATEADD(day, -180, getdate())

return @@error
go

exec dbo.p1
go

Tambien puedes hacerlo de la sgte forma:

create procedure dbo.p1
@d datetime
as
set nocount on

select c1, c2, cn
from dbo.t1
where fecha <= @d

return @@error
go

declare @d datetime

set @d = DATEADD(day, -180, getdate())

exec dbo.p1 @d
go

Todo esto lo puedes leer en los sgtes articulos:

Estadísticas de Distribución en SQL Server 2000 (1)
http://www.portalsql.com/

Estadísticas de Distribución en SQL Server 2000 (2)
http://www.portalsql.com/

SQL Server y la Autoparametrización
http://www.portalsql.com/


AMB

"Isaias" wrote:

Estoy metido en una duda, ¿Que sera mejor o mas eficiente?

1..
SELECT *
FROM MyTabla
WHERE datediff(dd,MyColFecha,getdate()) > 180

2..
DECLARE @MyFecha datetime
SET @MyFecha = DATEADD(day, -180, getdate())

SELECT *
FROM MyTabla
WHERE MyColFecha <= @MyFecha

Saludos
IIslas

Hola, que cantidad de registros tienes? nos podrias pasar el plan de
ejecucion?
Tienes triggers? Foreign key?


Salu2

Microsoft MVP SQL Server
Culminis Speaker

"Isaias" escribió en el mensaje
news:

Indices:

idx_FechaHora clustered located on PRIMARY FechaHora
idx_trans_1 nonclustered located on PRIMARY Usuario
idx_trans_2 nonclustered located on PRIMARY Moneda
idx_trans_3 nonclustered located on PRIMARY TurnoAMPM
idx_trans_4 nonclustered located on PRIMARY Codigo
idx_transacc nonclustered located on PRIMARY Usuario, TurnoAMPM, Moneda
_WA_Sys_Folio_60A75C0F nonclustered, statistics, auto create located on
PRIMARY Folio
_WA_Sys_Reversada_60A75C0F nonclustered, statistics, auto create located
on
PRIMARY Reversada
_WA_Sys_FechaHora_60A75C0F nonclustered, statistics, auto create located
on
PRIMARY FechaHora
s1 nonclustered, statistics, stats no recompute located on PRIMARY
FechaHora

No tiene ligas con otras tablas.

Saludos
IIslas


"Alejandro Mesa" wrote:

Isaias,

- Cuantos indices tiene esa tabla?
- Que hay de restricciones "foreign key" que la referencian?

Todo eso influye en la demora de la sentencia "delete". En cuanto a
renombrar la tabla, etc., falta informacion para poder decirte que es una
solucion adecuada.


AMB


"Isaias" wrote:

> Gracias a ambos (Maxi y Alex)
>
> Le cuento que de un total de 235,390 registros en la tabla a consultar
> (Query Analyzer), se tarda 1:50, para arrojarme 163,077 registros
> procesados
>
> Tengo un INDICE CLUSTERED por la columna fecha y utilice la opcion:
>
> where fecha <= DATEADD(day, -180, getdate())
>
> Esto me arroja el Statistics IO On:
>
> (163081 row(s) affected)
>
> Table 'mytable'. Scan count 1, logical reads 2837, physical reads 1,
> read-ahead reads 2520.
>
> Estoy intentando bajar el tiempo, ya que este store se ejecuta desde un
> aplicativo en VB y manda el ya famoso mesajes de TIME OUT, se que no es
> la
> mejor forma de ejecutarlo, estoy pensando cambiarlo a hacerlo mediante
> un JOB
> y que el VB unicamente "arranque" dicho job para realizar el DELETE.
>
> Se me habia olvidado decirles, que en relidad el proceso hace un DELETE
> de
> los regitros encontrados en el WHERE.
>
> Tal vez "rescatando" los registros que deban quedarse, mandarlos a otra
> tabla, darle un drop a la tabla original y un rename a la tabla de
> paso,
> funcionaria.
>
> ¿Como la ven?
>
>
>
>
>
>
>
> Saludos
> IIslas
>
>
> "Alejandro Mesa" wrote:
>
> > Isaias,
> >
> > Todavia falta informacion para darte una respuesta total.
> >
> > 1- Como ya indico Maxi, no se recomienda manipular las columnas en
> > las
> > expresiones de un JOIN on de la clausula WHERE, porque entonces SQL
> > Server no
> > considera esa expresion como una expresion de busqueda y no intentara
> > hacer
> > un analisis de los indices de la tabla para resolver esa busqueda.
> >
> > 2 - La segunda forma te dara un probabilidad mayor de que algun
> > indice pueda
> > ser usado, pero al usar una variable intermedia, SQL Server no hara
> > uso del
> > histograma de distribucion de valores en la llave del indice adecuado
> > y usara
> > la densidad de las columnas que participan en esa expresion y que
> > forman
> > parte de la llave del indice, para determinar laoperacion que se
> > llevara a
> > cabo sobre ese indice (plan de ejecucion). SQL Server usa los valores
> > que son
> > conocidos en tiempo de compilacion, por lo que cualquier referencia a
> > una
> > variable intermedia no sera usada para analizar el histograma de
> > distribucion
> > de valores. Si vas a usar esa sentencia en un procedimiento
> > almacenado,
> > entonces usa el parametro en la expresion de la clausula WHERE
> > directamente.
> >
> > Ejemplo:
> >
> > create procedure dbo.p1
> > as
> > set nocount on
> >
> > select c1, c2, cn
> > from dbo.t1
> > where fecha <= DATEADD(day, -180, getdate())
> >
> > return @@error
> > go
> >
> > exec dbo.p1
> > go
> >
> > Tambien puedes hacerlo de la sgte forma:
> >
> > create procedure dbo.p1
> > @d datetime
> > as
> > set nocount on
> >
> > select c1, c2, cn
> > from dbo.t1
> > where fecha <= @d
> >
> > return @@error
> > go
> >
> > declare @d datetime
> >
> > set @d = DATEADD(day, -180, getdate())
> >
> > exec dbo.p1 @d
> > go
> >
> > Todo esto lo puedes leer en los sgtes articulos:
> >
> > Estadísticas de Distribución en SQL Server 2000 (1)
> > http://www.portalsql.com/
> >
> > Estadísticas de Distribución en SQL Server 2000 (2)
> > http://www.portalsql.com/
> >
> > SQL Server y la Autoparametrización
> > http://www.portalsql.com/
> >
> >
> > AMB
> >
> > "Isaias" wrote:
> >
> > > Estoy metido en una duda, ¿Que sera mejor o mas eficiente?
> > >
> > > 1..
> > > SELECT *
> > > FROM MyTabla
> > > WHERE datediff(dd,MyColFecha,getdate()) > 180
> > >
> > > 2..
> > > DECLARE @MyFecha datetime
> > > SET @MyFecha = DATEADD(day, -180, getdate())
> > >
> > > SELECT *
> > > FROM MyTabla
> > > WHERE MyColFecha <= @MyFecha
> > >
> > > Saludos
> > > IIslas

Hola Isaias,

piensa que el query necesita devolver muchísimas filas... más de la mitad, y
todas las columnas, por lo que dudo mucho que el plan de ejecución sea
distinto de un clustered index scan (o table scan en caso de no tener índice
clustered).

Intuyo que se hacen muchas lecturas de páginas a disco y luego se envian al
cliente. ¿Se ejecuta con frecuencia esa consulta? ¿has detectado problemas
de memoria, disco, red?


Saludos,

Eladio Rincón,
Mentor Solid Quality Learning
SQL Server MVP


Visita mi página web
Artículos, recursos y trucos de SQL Server 2000 y 2005
http://www.siquelnet.com


"Isaias" wrote in message
news:

Claro Maxi

Esto lo puse en una posta anterior:

Le cuento que de un total de 235,390 registros en la tabla a consultar
(Query Analyzer), se tarda 1:50, para arrojarme 163,077 registros
procesados

No hay triggers

Solo tengo un DEFAULT (getdate()) sobre la columna fecha

DEFAULT on column
FechaHora DF__sm_jrn_tr__Fecha__37703C52 (n/a) (n/a) (getdate())

En un momento te mando el PLAN DE EJECUCION.


Saludos
IIslas


"Maxi" wrote:

Hola, que cantidad de registros tienes? nos podrias pasar el plan de
ejecucion?
Tienes triggers? Foreign key?


Salu2

Microsoft MVP SQL Server
Culminis Speaker

"Isaias" escribió en el mensaje
news:
> Indices:
>
> idx_FechaHora clustered located on PRIMARY FechaHora
> idx_trans_1 nonclustered located on PRIMARY Usuario
> idx_trans_2 nonclustered located on PRIMARY Moneda
> idx_trans_3 nonclustered located on PRIMARY TurnoAMPM
> idx_trans_4 nonclustered located on PRIMARY Codigo
> idx_transacc nonclustered located on PRIMARY Usuario, TurnoAMPM, Moneda
> _WA_Sys_Folio_60A75C0F nonclustered, statistics, auto create located on
> PRIMARY Folio
> _WA_Sys_Reversada_60A75C0F nonclustered, statistics, auto create
> located
> on
> PRIMARY Reversada
> _WA_Sys_FechaHora_60A75C0F nonclustered, statistics, auto create
> located
> on
> PRIMARY FechaHora
> s1 nonclustered, statistics, stats no recompute located on PRIMARY
> FechaHora
>
> No tiene ligas con otras tablas.
>
> Saludos
> IIslas
>
>
> "Alejandro Mesa" wrote:
>
>> Isaias,
>>
>> - Cuantos indices tiene esa tabla?
>> - Que hay de restricciones "foreign key" que la referencian?
>>
>> Todo eso influye en la demora de la sentencia "delete". En cuanto a
>> renombrar la tabla, etc., falta informacion para poder decirte que es
>> una
>> solucion adecuada.
>>
>>
>> AMB
>>
>>
>> "Isaias" wrote:
>>
>> > Gracias a ambos (Maxi y Alex)
>> >
>> > Le cuento que de un total de 235,390 registros en la tabla a
>> > consultar
>> > (Query Analyzer), se tarda 1:50, para arrojarme 163,077 registros
>> > procesados
>> >
>> > Tengo un INDICE CLUSTERED por la columna fecha y utilice la opcion:
>> >
>> > where fecha <= DATEADD(day, -180, getdate())
>> >
>> > Esto me arroja el Statistics IO On:
>> >
>> > (163081 row(s) affected)
>> >
>> > Table 'mytable'. Scan count 1, logical reads 2837, physical reads 1,
>> > read-ahead reads 2520.
>> >
>> > Estoy intentando bajar el tiempo, ya que este store se ejecuta desde
>> > un
>> > aplicativo en VB y manda el ya famoso mesajes de TIME OUT, se que no
>> > es
>> > la
>> > mejor forma de ejecutarlo, estoy pensando cambiarlo a hacerlo
>> > mediante
>> > un JOB
>> > y que el VB unicamente "arranque" dicho job para realizar el DELETE.
>> >
>> > Se me habia olvidado decirles, que en relidad el proceso hace un
>> > DELETE
>> > de
>> > los regitros encontrados en el WHERE.
>> >
>> > Tal vez "rescatando" los registros que deban quedarse, mandarlos a
>> > otra
>> > tabla, darle un drop a la tabla original y un rename a la tabla de
>> > paso,
>> > funcionaria.
>> >
>> > ¿Como la ven?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Saludos
>> > IIslas
>> >
>> >
>> > "Alejandro Mesa" wrote:
>> >
>> > > Isaias,
>> > >
>> > > Todavia falta informacion para darte una respuesta total.
>> > >
>> > > 1- Como ya indico Maxi, no se recomienda manipular las columnas en
>> > > las
>> > > expresiones de un JOIN on de la clausula WHERE, porque entonces
>> > > SQL
>> > > Server no
>> > > considera esa expresion como una expresion de busqueda y no
>> > > intentara
>> > > hacer
>> > > un analisis de los indices de la tabla para resolver esa busqueda.
>> > >
>> > > 2 - La segunda forma te dara un probabilidad mayor de que algun
>> > > indice pueda
>> > > ser usado, pero al usar una variable intermedia, SQL Server no
>> > > hara
>> > > uso del
>> > > histograma de distribucion de valores en la llave del indice
>> > > adecuado
>> > > y usara
>> > > la densidad de las columnas que participan en esa expresion y que
>> > > forman
>> > > parte de la llave del indice, para determinar laoperacion que se
>> > > llevara a
>> > > cabo sobre ese indice (plan de ejecucion). SQL Server usa los
>> > > valores
>> > > que son
>> > > conocidos en tiempo de compilacion, por lo que cualquier
>> > > referencia a
>> > > una
>> > > variable intermedia no sera usada para analizar el histograma de
>> > > distribucion
>> > > de valores. Si vas a usar esa sentencia en un procedimiento
>> > > almacenado,
>> > > entonces usa el parametro en la expresion de la clausula WHERE
>> > > directamente.
>> > >
>> > > Ejemplo:
>> > >
>> > > create procedure dbo.p1
>> > > as
>> > > set nocount on
>> > >
>> > > select c1, c2, cn
>> > > from dbo.t1
>> > > where fecha <= DATEADD(day, -180, getdate())
>> > >
>> > > return @@error
>> > > go
>> > >
>> > > exec dbo.p1
>> > > go
>> > >
>> > > Tambien puedes hacerlo de la sgte forma:
>> > >
>> > > create procedure dbo.p1
>> > > @d datetime
>> > > as
>> > > set nocount on
>> > >
>> > > select c1, c2, cn
>> > > from dbo.t1
>> > > where fecha <= @d
>> > >
>> > > return @@error
>> > > go
>> > >
>> > > declare @d datetime
>> > >
>> > > set @d = DATEADD(day, -180, getdate())
>> > >
>> > > exec dbo.p1 @d
>> > > go
>> > >
>> > > Todo esto lo puedes leer en los sgtes articulos:
>> > >
>> > > Estadísticas de Distribución en SQL Server 2000 (1)
>> > > http://www.portalsql.com/
>> > >
>> > > Estadísticas de Distribución en SQL Server 2000 (2)
>> > > http://www.portalsql.com/
>> > >
>> > > SQL Server y la Autoparametrización
>> > > http://www.portalsql.com/
>> > >
>> > >
>> > > AMB
>> > >
>> > > "Isaias" wrote:
>> > >
>> > > > Estoy metido en una duda, ¿Que sera mejor o mas eficiente?
>> > > >
>> > > > 1..
>> > > > SELECT *
>> > > > FROM MyTabla
>> > > > WHERE datediff(dd,MyColFecha,getdate()) > 180
>> > > >
>> > > > 2..
>> > > > DECLARE @MyFecha datetime
>> > > > SET @MyFecha = DATEADD(day, -180, getdate())
>> > > >
>> > > > SELECT *
>> > > > FROM MyTabla
>> > > > WHERE MyColFecha <= @MyFecha
>> > > >
>> > > > Saludos
>> > > > IIslas

Oye Isaías,

Esa operación que estás haciendo parece una operación de limpieza de datos
antiguos, por la forma que tiene la cláusula where, diría que es una
operación que debería ejecutarse de forma periódica. Por tanto, ¿No crees
que sería mejor automatizarla en un Job, en vez de requerir intervención del
usuario?. Por otra parte, son muchos los registros que se eliminan y tarda
un buen rato, así que parece que durante esa operación podría quedarse
completamente bloqueada la tabla y otros usuarios que quisieran acceder
recibirían timeouts mientras dure la operación.

En una ocasión tuve un problema parecido. Era una aplicación que en la que
los usuarios accedían constantemente a una tabla las 24 horas del día, 365
días al año, era una aplicación que recibía alarmas de seguridad y
notificaciones de estado de dispositivos de seguirdad de bancos. La
aplicación se ejecutaba en un centro de una companía de seguridad. Los datos
antiguos había que eliminarlos y eran muchos los que se producían a lo largo
del día. Así que hice un job que se ejecutaba diáriamente, y para evitar que
los bloqueos establecidos por el comando delete y dada la larga duración de
la transacción ,decidí eliminar cada registro en su propia transacción, para
ello utilicé un cursor de sólo lectura y hacia delante con el que iba
obteniendo la clave primaria y luego ejecutaba el delete con la clave
primaria en la where. El procedimiento de limpieza no era lo más eficiente
del mundo, de hecho tardaba bastante más en completarse que usando una única
transacción larga con un sólo delete. Pero eso no era lo que importaba, lo
importante era que no bloqueara el trabajo de los usuarios. El procedimiento
se ejecutaba sin que se notara absolutamente nada en la aplicación.

Siento haber soltado este rollo, pero sabiendo la mala fama que tienen los
cursores quería justificarlo suficientemente. No vaya a ser que se me eche
encima la "Liga Anticursores" que anda por aquí :-)

Saludos:


Jesús López
www.solidqualitylearning.com




"Isaias" escribió en el mensaje
news:

Claro Maxi

Esto lo puse en una posta anterior:

Le cuento que de un total de 235,390 registros en la tabla a consultar
(Query Analyzer), se tarda 1:50, para arrojarme 163,077 registros
procesados

No hay triggers

Solo tengo un DEFAULT (getdate()) sobre la columna fecha

DEFAULT on column
FechaHora DF__sm_jrn_tr__Fecha__37703C52 (n/a) (n/a) (getdate())

En un momento te mando el PLAN DE EJECUCION.


Saludos
IIslas


"Maxi" wrote:

Hola, que cantidad de registros tienes? nos podrias pasar el plan de
ejecucion?
Tienes triggers? Foreign key?


Salu2

Microsoft MVP SQL Server
Culminis Speaker

"Isaias" escribió en el mensaje
news:
> Indices:
>
> idx_FechaHora clustered located on PRIMARY FechaHora
> idx_trans_1 nonclustered located on PRIMARY Usuario
> idx_trans_2 nonclustered located on PRIMARY Moneda
> idx_trans_3 nonclustered located on PRIMARY TurnoAMPM
> idx_trans_4 nonclustered located on PRIMARY Codigo
> idx_transacc nonclustered located on PRIMARY Usuario, TurnoAMPM, Moneda
> _WA_Sys_Folio_60A75C0F nonclustered, statistics, auto create located on
> PRIMARY Folio
> _WA_Sys_Reversada_60A75C0F nonclustered, statistics, auto create
> located
> on
> PRIMARY Reversada
> _WA_Sys_FechaHora_60A75C0F nonclustered, statistics, auto create
> located
> on
> PRIMARY FechaHora
> s1 nonclustered, statistics, stats no recompute located on PRIMARY
> FechaHora
>
> No tiene ligas con otras tablas.
>
> Saludos
> IIslas
>
>
> "Alejandro Mesa" wrote:
>
>> Isaias,
>>
>> - Cuantos indices tiene esa tabla?
>> - Que hay de restricciones "foreign key" que la referencian?
>>
>> Todo eso influye en la demora de la sentencia "delete". En cuanto a
>> renombrar la tabla, etc., falta informacion para poder decirte que es
>> una
>> solucion adecuada.
>>
>>
>> AMB
>>
>>
>> "Isaias" wrote:
>>
>> > Gracias a ambos (Maxi y Alex)
>> >
>> > Le cuento que de un total de 235,390 registros en la tabla a
>> > consultar
>> > (Query Analyzer), se tarda 1:50, para arrojarme 163,077 registros
>> > procesados
>> >
>> > Tengo un INDICE CLUSTERED por la columna fecha y utilice la opcion:
>> >
>> > where fecha <= DATEADD(day, -180, getdate())
>> >
>> > Esto me arroja el Statistics IO On:
>> >
>> > (163081 row(s) affected)
>> >
>> > Table 'mytable'. Scan count 1, logical reads 2837, physical reads 1,
>> > read-ahead reads 2520.
>> >
>> > Estoy intentando bajar el tiempo, ya que este store se ejecuta desde
>> > un
>> > aplicativo en VB y manda el ya famoso mesajes de TIME OUT, se que no
>> > es
>> > la
>> > mejor forma de ejecutarlo, estoy pensando cambiarlo a hacerlo
>> > mediante
>> > un JOB
>> > y que el VB unicamente "arranque" dicho job para realizar el DELETE.
>> >
>> > Se me habia olvidado decirles, que en relidad el proceso hace un
>> > DELETE
>> > de
>> > los regitros encontrados en el WHERE.
>> >
>> > Tal vez "rescatando" los registros que deban quedarse, mandarlos a
>> > otra
>> > tabla, darle un drop a la tabla original y un rename a la tabla de
>> > paso,
>> > funcionaria.
>> >
>> > ¿Como la ven?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > Saludos
>> > IIslas
>> >
>> >
>> > "Alejandro Mesa" wrote:
>> >
>> > > Isaias,
>> > >
>> > > Todavia falta informacion para darte una respuesta total.
>> > >
>> > > 1- Como ya indico Maxi, no se recomienda manipular las columnas en
>> > > las
>> > > expresiones de un JOIN on de la clausula WHERE, porque entonces
>> > > SQL
>> > > Server no
>> > > considera esa expresion como una expresion de busqueda y no
>> > > intentara
>> > > hacer
>> > > un analisis de los indices de la tabla para resolver esa busqueda.
>> > >
>> > > 2 - La segunda forma te dara un probabilidad mayor de que algun
>> > > indice pueda
>> > > ser usado, pero al usar una variable intermedia, SQL Server no
>> > > hara
>> > > uso del
>> > > histograma de distribucion de valores en la llave del indice
>> > > adecuado
>> > > y usara
>> > > la densidad de las columnas que participan en esa expresion y que
>> > > forman
>> > > parte de la llave del indice, para determinar laoperacion que se
>> > > llevara a
>> > > cabo sobre ese indice (plan de ejecucion). SQL Server usa los
>> > > valores
>> > > que son
>> > > conocidos en tiempo de compilacion, por lo que cualquier
>> > > referencia a
>> > > una
>> > > variable intermedia no sera usada para analizar el histograma de
>> > > distribucion
>> > > de valores. Si vas a usar esa sentencia en un procedimiento
>> > > almacenado,
>> > > entonces usa el parametro en la expresion de la clausula WHERE
>> > > directamente.
>> > >
>> > > Ejemplo:
>> > >
>> > > create procedure dbo.p1
>> > > as
>> > > set nocount on
>> > >
>> > > select c1, c2, cn
>> > > from dbo.t1
>> > > where fecha <= DATEADD(day, -180, getdate())
>> > >
>> > > return @@error
>> > > go
>> > >
>> > > exec dbo.p1
>> > > go
>> > >
>> > > Tambien puedes hacerlo de la sgte forma:
>> > >
>> > > create procedure dbo.p1
>> > > @d datetime
>> > > as
>> > > set nocount on
>> > >
>> > > select c1, c2, cn
>> > > from dbo.t1
>> > > where fecha <= @d
>> > >
>> > > return @@error
>> > > go
>> > >
>> > > declare @d datetime
>> > >
>> > > set @d = DATEADD(day, -180, getdate())
>> > >
>> > > exec dbo.p1 @d
>> > > go
>> > >
>> > > Todo esto lo puedes leer en los sgtes articulos:
>> > >
>> > > Estadísticas de Distribución en SQL Server 2000 (1)
>> > > http://www.portalsql.com/
>> > >
>> > > Estadísticas de Distribución en SQL Server 2000 (2)
>> > > http://www.portalsql.com/
>> > >
>> > > SQL Server y la Autoparametrización
>> > > http://www.portalsql.com/
>> > >
>> > >
>> > > AMB
>> > >
>> > > "Isaias" wrote:
>> > >
>> > > > Estoy metido en una duda, ¿Que sera mejor o mas eficiente?
>> > > >
>> > > > 1..
>> > > > SELECT *
>> > > > FROM MyTabla
>> > > > WHERE datediff(dd,MyColFecha,getdate()) > 180
>> > > >
>> > > > 2..
>> > > > DECLARE @MyFecha datetime
>> > > > SET @MyFecha = DATEADD(day, -180, getdate())
>> > > >
>> > > > SELECT *
>> > > > FROM MyTabla
>> > > > WHERE MyColFecha <= @MyFecha
>> > > >
>> > > > Saludos
>> > > > IIslas