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

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

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
>
>
>

te explicas perfecto, pero no lo haria con Sqldinamico sino con las
diferentes combinaciones.

Yo le trato de esquivar al Sqldinamico, y prefiero hacer todas las
combinaciones en mi Store (de si no es problema eso para SqlServer ni para
vos si sos ordenado)

Salu2



Maximiliano Damian Accotto


"Lic. Jose Aguilera Iglesias" escribió en el mensaje
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 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
> >
> >
> >
>
>

Estas son tablas de un sistema en uso en estos momentos con unos cuantos
miles de records
Tienes definidos varios indices.

Estos son los indices de las dos tablas

Order Head
==IX_OrderHead nonclustered located on PRIMARY DocDate
IX_OrderHead_1 nonclustered located on PRIMARY Ref
IX_OrderHead_2 nonclustered located on PRIMARY CustID
IX_OrderHead_3 nonclustered located on PRIMARY ShippingDate
IX_OrderHead_4 nonclustered located on PRIMARY RequestDate
IX_OrderHead_5 nonclustered located on PRIMARY PurAgent
IX_OrderHead_6 nonclustered located on PRIMARY ShipLoct
IX_OrderHead_7 nonclustered located on PRIMARY DeptID
IX_OrderHead_8 nonclustered located on PRIMARY SubDeptID
IX_OrderHead_9 nonclustered located on PRIMARY DocNo
PK_OrderHead nonclustered, unique, primary key located on PRIMARY CompID,
DocNo

OrderDet
IX_OrderDet nonclustered located on PRIMARY Supplier
IX_OrderDet_1 nonclustered located on PRIMARY RegionID
IX_OrderDet_2 nonclustered located on PRIMARY QuoteID
IX_OrderDet_3 nonclustered located on PRIMARY ProdID
IX_OrderDet_4 nonclustered located on PRIMARY LotID
IX_OrderDet_5 nonclustered located on PRIMARY ProdID, LotID
IX_OrderDet_6 nonclustered located on PRIMARY Supplier, ProdID, LotID
IX_OrderDet_7 nonclustered located on PRIMARY Vendor
IX_OrderDet_8 nonclustered located on PRIMARY DocNo
OrderDet5 nonclustered located on PRIMARY DocNo, CompID, Qty, Price
PK_OrderDet nonclustered, unique, primary key located on PRIMARY CompID,
DocNo, Line


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