Ayuda con Procedimiento Almacenado ( Parametro )

Hola,

On 4 nov, 17:31, Francizk0 wrote:
Mostrar la cita

Q tal gente otra ves acudiendo a uds.
tengo el sgt problema o duda ??

Tengo un SP el cual una de las condicion utilizon el IN , el WHERE es
algo asi
WHERE Campo IN ( @Parametro ) , ahi todo bien lo que ocurre es q como
mando @Parametro si quiero q valga
algo asi :
@Parametro = 'xx-xxxx' , 'xx-xxxx' , 'xx-xxxx'
yq qye solo funciona si lo mando :
@Parametro = 'xx-xxxx', es decir con una valor
mi duda es de que forma puedo hacer que @Parametro sea como el primer
caso
Utilizo Win XP y MS-SQL 2000

Tienes que hacerlo con sql dinámico. Digamos que en
@parametro recibes algo como 'xx-xxxx, yy-yyyy, zz-zzzz'.
Entonces puedes hacer algo así:

exec ('select * from tabla where campo in (' + @parametro + ')')

Saludos,
Carlos

No te funciona porque eso no es posible.

Echa un vistazo al artículo de Erland Sommarskog sobre parámetros en SQL
Server: http://www.sommarskog.se/arrays-in-sql-2000.html

"Francizk0" wrote:

Mostrar la cita

Q tal gente otra ves acudiendo a uds.
tengo el sgt problema o duda ??

Tengo un SP el cual una de las condicion utilizon el IN , el WHERE es
algo asi
WHERE Campo IN ( @Parametro ) , ahi todo bien lo que ocurre es q como
mando @Parametro si quiero q valga
algo asi :
@Parametro = 'xx-xxxx' , 'xx-xxxx' , 'xx-xxxx'
yq qye solo funciona si lo mando :
@Parametro = 'xx-xxxx', es decir con una valor
mi duda es de que forma puedo hacer que @Parametro sea como el primer
caso
Utilizo Win XP y MS-SQL 2000

Alguna idea????????

Pero presta mucha atencion a lo que contiene ese parametro, pues esa es una
forma que se puede explotar para injectar codigo sql. El problema esta en que
a SQL Server se le puede enviar un lote de intrucciones, por lo que al
concatenar cadenas entradas por el usuario, el codigo final puede resultar en
algo inesperado. Una forma de evitar la injeccion de codigo t-sql es no
concatenando cadenas entradas por el usuario.

use northwind
go

declare @parametro varchar(128)

set @parametro = '1, 2, 3); drop table dbo.orders; select (1'

select 'select * from dbo.orders where orderid in (' + @parametro + ')'
go

Resultado:

select * from dbo.orders where orderid in (1, 2, 3);
drop table dbo.orders;
select (1)


The Curse and Blessings of Dynamic SQL
http://www.sommarskog.se/dynamic_sql.html


AMB



"Carlos M. Calvelo" wrote:

Mostrar la cita

Hola,

On 4 nov, 17:31, Francizk0 wrote:
> Q tal gente otra ves acudiendo a uds.
> tengo el sgt problema o duda ??
>
> Tengo un SP el cual una de las condicion utilizon el IN , el WHERE es
> algo asi
> WHERE Campo IN ( @Parametro ) , ahi todo bien lo que ocurre es q como
> mando @Parametro si quiero q valga
> algo asi :
> @Parametro = 'xx-xxxx' , 'xx-xxxx' , 'xx-xxxx'
> yq qye solo funciona si lo mando :
> @Parametro = 'xx-xxxx', es decir con una valor
> mi duda es de que forma puedo hacer que @Parametro sea como el primer
> caso
> Utilizo Win XP y MS-SQL 2000
>

Tienes que hacerlo con sql dinámico. Digamos que en
@parametro recibes algo como 'xx-xxxx, yy-yyyy, zz-zzzz'.
Entonces puedes hacer algo así:

exec ('select * from tabla where campo in (' + @parametro + ')')

Saludos,
Carlos

Hola Alejandro,

On 4 nov, 20:26, Alejandro Mesa
wrote:
Mostrar la cita

Pero presta mucha atencion a lo que contiene ese parametro, pues esa es una
forma que se puede explotar para injectar codigo sql. El problema esta en que
a SQL Server se le puede enviar un lote de intrucciones, por lo que al
concatenar cadenas entradas por el usuario, el codigo final puede resultar en
algo inesperado. Una forma de evitar la injeccion de codigo t-sql es no
concatenando cadenas entradas por el usuario.

use northwind
go

declare @parametro varchar(128)

set @parametro = '1, 2, 3); drop table dbo.orders; select (1'

select 'select * from dbo.orders where orderid in (' + @parametro + ')'
go

Resultado:

select * from dbo.orders where orderid in (1, 2, 3);
drop table dbo.orders;
select (1)

The Curse and Blessings of Dynamic SQLhttp://www.sommarskog.se/dynamic_sql.html

Si Alejandro. Era consciente de ello cuando lo escribí.
Obviamente aquí el cliente (aplicación) tiene una responsabilidad
bastante seria.

Pero no he visto otra forma dado como está planteado el
problema. Quizás se encuentre algo mas inteligente en la
página de sommarskog !?

Gracias por la puntualización,
Carlos

Hola otra vez Alejandro,

Sin quitarle seriedad al asunto también añadir que
con una base de datos bien diseñada (estoy pensando
en permisos) no cualquier conexión puede hacer así
si más un drop table por ejemplo. Y si lo que se
inyecta es permitido pues bien hecho está.

Ese es el otro extremo en el asunto de la inyección
de código. Pero repito que es sin quitarle importancia
a tu puntualización.

Saludos,
Carlos