Como ejecutar un Query por desde SQL Server usando parámetros

Ademas esta es la cantidad de records

Order Head : 18133
Order Det : 499226


Saludos,

Norman



"Adrian Garcia" wrote in message
news:

Si no tienes definido ningun indice en las tablas (ni siquiera un primary
key, por eso realiza TABLE SCAN y no un CLUSTER INDEX SCAN) va a ser medio
imposible comparar los 2 queries.
Probemos con agregarle a las 2 tablas los primary key y definirle un

indice

adicional por el campo fecha.
Tambien seria muy bueno que tengamos las estadisticas de IO para comparar
bien los resultados.

Saludos
Adrian D. Garcia
NDSoft

Y aqui tienes el resultado de las estadisticas de IO para que saques
conclusiones :-)

(27630 row(s) affected)

Table 'OrderDet'. Scan count 1, logical reads 8462, physical reads 0,
read-ahead reads 0.
Table 'OrderHead'. Scan count 1, logical reads 448, physical reads 0,
read-ahead reads 0.



(27630 row(s) affected)

Table 'OrderDet'. Scan count 1, logical reads 8462, physical reads 0,
read-ahead reads 0.
Table 'OrderHead'. Scan count 1, logical reads 448, physical reads 0,
read-ahead reads 0.


Saludos,

Norman



"Adrian Garcia" wrote in message
news:

Si no tienes definido ningun indice en las tablas (ni siquiera un primary
key, por eso realiza TABLE SCAN y no un CLUSTER INDEX SCAN) va a ser medio
imposible comparar los 2 queries.
Probemos con agregarle a las 2 tablas los primary key y definirle un

indice

adicional por el campo fecha.
Tambien seria muy bueno que tengamos las estadisticas de IO para comparar
bien los resultados.

Saludos
Adrian D. Garcia
NDSoft

Hmmm...
Es buena, yo la utilizaba hasta que vi los planes de ejecucion que
generaban: todos table o cluster index scan aun cuando solo accedia por la
clave primaria.

Si se concatenan a mano el plan de ejecucion es mas optimo aunque eso obliga
al motor a recompilar cada vez que se ejecuta la setencia SQL.

Si dentro de un stored realizas las combinaciones de parametros es en teoria
lo mejor de los 2 mundos, pero con 24 parametros ni loco se puede hacer, ni
se calcular todas las combinaciones posibles... de 24 tomados de a 1 + 24
tomados de a 2 + 24 tomados de 3 je! creo que sobrepasaria el limite de
los 128KB que tiene un procedimiento almacenado.

Saludos
Adrian D. Garcia
NDSoft


"Norman A. Armas" wrote in message
news:%

Si pones el parametro como nulo puedes lograr el WHERE

ejemplo
@FechaEmisionInicial = '15/01/2003'
@FechaEmisionFinal = NULL

TuTabla.FechaEmision >= isnull(@FechaEmisionInicial,TuTabla.FechaEmision)
AND

TuTabla.FechaEmision <= isnull(@FechaEmisionFinal,TuTabla.FechaEmision)
etc

> Saludos,

Norman



"Lic. Jose Aguilera Iglesias" wrote in message
news:
> Hola y gracias por la inmediatez !!
>
> El problema es que estoy trabajando en un Stored Procedure de busqueda

al

> que le paso 23 parametros (una especie de búsqueda personalizada que le
> brinda al usuario todos los campos para que el escoja, teniendo en

cuenta

> que el default es "todos"). En dicho procedimiento yo utilizo un where

un

> poco extenso para el resultado pues utilizo el like concatenado a los
> parametros que me pasan (
> where (Medida like '%'+@Medida+'%' and FechaEmision >> @FechaEmisionInicial
> and FechaEmision <= @FechaEmisionFinal and FechaSolucion >> > @FechaSolucionInicial and FechaSolucion <= @FechaSolucionFinal and
> DivisionCliente like '%'+@DivisionCliente+'%' +...).
>
> De los 24 parámteros, 4 son relacionados con dos rangos de Fechas (rango
de
> Fecha de Emisión y rango de Fecha de Solución). Como estos son del tipo
> "datetime" no puedo utilizar el like sino compararlos como tal. Ahora el
> problema es el siguiente: Cualquiera de los 4 parámetros de las Fechas
> pueden estar vacíos implicando que no importa el respectivo parámetro
>
> por ejemplo:
>
> @FechaEmisionInicial = '15/01/2003',
>
> @FechaEmisionFinal = ' ',
>
> @FechaSolucionInicial = ' ',
>
> @FechaSolucionFinal = '01/01/2004 ',
>
> especifica que le interesan todos los registros cuya Fecha de Emisión

sean

> mayor o igual a 15/01/2003 y cuya Fecha de Solución sea menor que
> 01/01/2004.
>
> Para lograr esto se tendría que excluir del "where" la parte equivalente

a

> FechaEmisionFinal y FechaSolucionInicial, por eso he pensado que, para
> evitarme chquear cada una de las 16 combinaciones que pueden existir,
> pudiera ir construyendo la cadena de acuerdo a los parámetros que no

sean

> null.
>
> Me explico mejor?.
>
> Agradecería cualquier consejo al respecto.
>
> jaigle
>
> "Maximiliano D. A." <maxi_accotto[arroba]speedy[.]com[.]ar> wrote in
message
> news:
> > Hola, mira eso se hace con SqlDinamico, ej:
> >
> > declare @string as nvarchar(1000)
> >
> > set @string = N'Select * from customers
> >
> > Exec sp_executesql @string
> >
> > ojo que no es una tecnica recomenda en lo absoluto, solo si no queda
otra.
> >
> > Porque no nos cuenta mejor que desea hacer y vemos si no podemos

evitar

el
> > uso de SqlDinamico
> >
> > Gracias
> >
> > Maximiliano Damian Accotto
> >
> >
> > "Lic. Jose Aguilera Iglesias" escribió en el
mensaje
> > news:
> > > Hola Foro:
> > >
> > > Quisiera saber cómo se pudiera lograr construir un Query dentro de

un

> > Stored
> > > Procedure y luego ejecutarlo.
> > >
> > > Sería algo así como:
> > >
> > > declare @cad varchar
> > > set @cad = 'select * from Tabla'
> > >
> > > ...y ahora poder ejecutar un llamado a ese Query para ejecutarlo.
> > >
> > >
> > > Agradeciendoles de antemano
> > >
> > > jaigle
> > >
> > >
> > >
> >
> >
>
>

Si no tienes definido ningun indice en las tablas (ni siquiera un primary
key, por eso realiza TABLE SCAN y no un CLUSTER INDEX SCAN) va a ser medio
imposible comparar los 2 queries.
Probemos con agregarle a las 2 tablas los primary key y definirle un indice
adicional por el campo fecha.
Tambien seria muy bueno que tengamos las estadisticas de IO para comparar
bien los resultados.

Saludos
Adrian D. Garcia
NDSoft

Contra, pero si te envie en un post anterior todos los idndices de todas las
tbals, este es el que tu buscas

IX_OrderHead_4 nonclustered located on PRIMARY RequestDate


Saludos,

Norman



"Adrian Garcia" wrote in message
news:%23M$

Curioso, no tienes ningun indice cluster (agrupado) sobre las consultas. A
menos que se indique lo contrario en el momento de la definicion de la
restriccion de la clave primaria, SQL Server crea un indice Cluster. Pero
seguramente debe haber existido algun motivo por el cual la clave primaria
fue definido asi.

Bien, lo que habria que ver, si puedes indicarlo, es si existe algun

indice

sobre la columna RequestDate.
Si no existe ese indice prodriamos probar agregando a la clausula where
alguna columna que tenga indice. Ahi estaremos en condiciones de ver si

hay

alguna diferencia.

Saludos
Adrian D. Garcia
NDSoft


"Norman A. Armas" wrote in message
news:
> Y aqui tienes el resultado de las estadisticas de IO para que saques
> conclusiones :-)
>
> (27630 row(s) affected)
>
> Table 'OrderDet'. Scan count 1, logical reads 8462, physical reads 0,
> read-ahead reads 0.
> Table 'OrderHead'. Scan count 1, logical reads 448, physical reads 0,
> read-ahead reads 0.
>
>
>
> (27630 row(s) affected)
>
> Table 'OrderDet'. Scan count 1, logical reads 8462, physical reads 0,
> read-ahead reads 0.
> Table 'OrderHead'. Scan count 1, logical reads 448, physical reads 0,
> read-ahead reads 0.
>
>
> Saludos,
>
> Norman
>
>
>
> "Adrian Garcia" wrote in message
> news:
> > Si no tienes definido ningun indice en las tablas (ni siquiera un
primary
> > key, por eso realiza TABLE SCAN y no un CLUSTER INDEX SCAN) va a ser
medio
> > imposible comparar los 2 queries.
> > Probemos con agregarle a las 2 tablas los primary key y definirle un
> indice
> > adicional por el campo fecha.
> > Tambien seria muy bueno que tengamos las estadisticas de IO para
comparar
> > bien los resultados.
> >
> > Saludos
> > Adrian D. Garcia
> > NDSoft
> >
> >
>
>