Pasar parámetros a un SP

"RafaPiula" wrote in message
news:

Hola a todos, tengo un SP para hacer una consulta y me interesa pasarle
una serie de parámetros al mismo campo. Estos parámetros, puede que
no sean los mismos para cada consulta, es decir, son del tipo
ClaveValor = 5 Or ClaveValor = 6 Or ClaveValor = 7 y en otra consulta,
un único parámetro, o ninguno, o más. Es decir, de antemano, no sé
los parámetros que le voy a enviar.
Cómo se los puedo pasar?

Bueno, el "ClaveValor = 5 Or ClaveValor = 6 Or ClaveValor = 7" lo puedes
convertir en "where ClaveValor in (5,6,7)", que te quedará más limpio. Por
desgracia, eso no resuelve el problema de pasarlo como parámetro al
procedimiento, porque no acepta que un parámetro sea una lista de valores
para el "IN".

La forma de resolverlo sería usar sql dinámico (que en sql server se consige
con una llamada a sp_executesql). El sp_executesql recibe como argumento un
string, y ese string se podría concatenar con la lista "5,6,7" mencionada
más arriba.

Por desgracia, el uso de sql dinámico anula muchas de las ventajas de usar
procedimientos almacenados, ya que ni ahorra el análisis de las sentencias,
ni las deja preoptimizadas, ni evita los ataques de inyección de sql.

En efecto como menciona Alberto pierdes algunas de las ventajas de los SP al
pasarles parámetros, pero algunas de ellas como el evitar el SQL Injection
lo puedes solucionar en tu código haciendo verificaciones anteriores.

De cualquier manera, hay ocasiones como mencionas que se necesita pasarle
parámetros de filtrado a un SP. Para hacer eso al momento de definir el SP
se declaran dichas variables de la siguiente manera:

CREATE PROCEDURE MiSP

@ClaveValor nvarchar(50) = '',

@ClaveFiltro nvarchar(50) = ''

AS

SELECT Campo1, Campo2


FROM Tabla WHERE Tabla.Campo3 = ClaveValor AND Tabla.Campo4 = ClaveFiltro

GO



Ya una vez que tienes definido y levantado el SP en tu servidor, para
llamarlo y pasarle los parámetros debes hacer algo como lo siguiente:



SqlDataAdapter sqlDA = new SqlDataAdapter("MiSP", sqlConn);

sqlDA.SelectCommand.CommandType = CommandType.StoredProcedure;

sqlDA.SelectCommand.Parameters.Add("@ClaveValor", SqlDbType.NVarChar);

sqlDA.SelectCommand.Parameters["@ClaveValor"].Value = "5";

sqlDA.SelectCommand.Parameters.Add("@ClaveFiltro", SqlDbType.NVarChar);

sqlDA.SelectCommand.Parameters["@ClaveFiltro"].Value = "Filtro";

sqlDA.Fill(dsResult);

Recuerda que es importante la parte de prevenir la inyección de SQL ya que
aunque el SP si esta precompilado y sólo es variable la parte de los
filtros, en estos pueden interrumpir la ejecución de tu comando y mandar
ejecutar los suyos.

Espero que con esto soluciones tu problema.

Saludos
FLY

"Alberto Poblacion"
escribió en el mensaje news:

"RafaPiula" wrote in message
news:

Hola a todos, tengo un SP para hacer una consulta y me interesa pasarle
una serie de parámetros al mismo campo. Estos parámetros, puede que
no sean los mismos para cada consulta, es decir, son del tipo
ClaveValor = 5 Or ClaveValor = 6 Or ClaveValor = 7 y en otra consulta,
un único parámetro, o ninguno, o más. Es decir, de antemano, no sé
los parámetros que le voy a enviar.
Cómo se los puedo pasar?

Bueno, el "ClaveValor = 5 Or ClaveValor = 6 Or ClaveValor = 7" lo puedes
convertir en "where ClaveValor in (5,6,7)", que te quedará más limpio. Por
desgracia, eso no resuelve el problema de pasarlo como parámetro al
procedimiento, porque no acepta que un parámetro sea una lista de valores
para el "IN".

La forma de resolverlo sería usar sql dinámico (que en sql server se
consige con una llamada a sp_executesql). El sp_executesql recibe como
argumento un string, y ese string se podría concatenar con la lista
"5,6,7" mencionada más arriba.

Por desgracia, el uso de sql dinámico anula muchas de las ventajas de usar
procedimientos almacenados, ya que ni ahorra el análisis de las
sentencias, ni las deja preoptimizadas, ni evita los ataques de inyección
de sql.