Otra consulta

15/07/2005 - 23:11 por Nicolas Ibarra Salazar | Informe spam
En una SELECT, cómo hago para pasarle más de un valor proveniente de un
combo que permita multiples selecciones:

Ej:
<select name="rubro" size="10" multiple>
<option value="1">Accesorios</option>
<option value="2">Servicios</option>
<option value="3">Depósito</option>

</select>

El tema es, en la query, cual es el operador para pasarle estos valores que
si no me equivoco van separados por comas?

SELECT * FROM rubros WHERE rubro "=" "IN" "ON" "IS" ??????

Probé con = y no trae ningun resultado cuando se elige mas de 1 opcion en el
combo.

Alguna idea?

Saludos.
Nicolas

Preguntas similare

Leer las respuestas

#11 Maxi
18/07/2005 - 16:36 | Informe spam
ok, para un solo valor lo que indicas es cierto.


Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
Maxi,

Desde mi primer post, me estoy refiriendo a simular arreglos uni
dimensionales (una sola dimension, una lista de valores) en t-sql. La
pregunta original fue como pasar una multi-seleccion a sql server. En
cuanto
a todo lo demas que tiene que ver con xml estoy de acuerdo y no lo he
puesto
en duda.

(para que inventar la rueda cuando otro ya la invento ;-), y ademas
cuando



Si asi hubiesen pensado los que crearon XML, entonces no lo hubieran
hecho,
pues XML al igual que HTML, fue tomado del estandard SGML.


AMB

"Maxi" wrote:

Hola Ale, sigamos que el tema es interesante :-)

> Lo mismo si usas las otras opciones y pones el codigo en una funcion de
> usuario que te devuelva una tabla con los valores pasados en la cadena.

mmm. no es tan asi, una cosa es una cadena XML que cualquier soft puede
interpretar ya que es un Standard y la otra es que vos te armes un modelo
y
luego le debas explicar a todos como funciona, no es lo mismo. El xml
desde
el cliente se genera con una simple instruccion y es un formato standard
el
cual no hay que inventar nada, si vos armas un formato para que de alguna
manera te pasen los datos, no es lo mismo. En tu mismo ejemplo veamos
como
hacemos una cosa: Vos ahi solo pasaste un campo y la cosa es simple
parece,
ahora veamos que sucede si debo pasar la linea de una OC (Orden de compra
por ej) es mas complejo porque tenes mas de un campo y ni hablar si el
dia
de mañana cambia la entrada, usando xml es totalmente transparente.

>> 3) Es muy simple de usar
>
> Lo mismo digo de los otros.

Con un solo campo si, ahora tenes 20 campos que pasar, es tan simple?

Te vuelvo a repetir lo mismo, con un solo campo lo veo entre comillas
bien,
por un lado no me es grato q vos definas un formato y no sea nada
Standard
(para que inventar la rueda cuando otro ya la invento ;-), y ademas
cuando
tenes una matriz compleja no veo facil solucion si no lo haces con XML,
hay
otras soluciones usando tablas temporales o sql-dinamico pero...

Yo cuando me referia a q lo tenia en produccion me referia a pasar
documentos como por ej OC, Facturas, etc. Y esto antes lo tenia de la
otra
manera, cuando empece a probar XML la diferencia fue muy notoria, no solo
en
perfomance, sino que tambien en facilidad, interpretacion, aislacion con
metodo StandarD (al cliente solo le digo, mandame un XML y ya, bue fueron
muchas las ventajas, ni hablar del manejo de transacciones y control de
errores.

Un abrazo


Salu2
Maxi


"Alejandro Mesa" escribió en el
mensaje news:
>> 1) Usas un formato standard y aislas mucho el SP's
>
> Lo mismo si usas las otras opciones y pones el codigo en una funcion de
> usuario que te devuelva una tabla con los valores pasados en la cadena.
>
>> 2) La performance como te indique no se ve casi nada afectada, yo como
>> te
>> dije lo uso mucho y en soft con muchas transacciones en un sistemas
>> ERP
>
> Hicistes alguna comparacion entre xml y los otros metodos?
>
>> 3) Es muy simple de usar
>
> Lo mismo digo de los otros.
>
>> 4) Es mucho mas seguro que usar SQL dinamico ;-)
>
> Nadie ha hablado de usar sql dinamico.
>
>> 5) Dejas todo bien armadito para sql2005 sin mayores cambios
>
> Lo mismo si usas una funcion definida de usuario.
>
>
> Maxi, no tengo nada en contra de usar xml, por el contrario, cuando
> quieres
> pasar multiple informacion por fila, o representar jerarquias, xml es
> la
> via
> correcta. Para simular un arreglo uni dimensional en t-sql, usar xml es
> una
> opcion posible pero no optima. La cantidad de informacion enviada
> atraves
> de
> la red es mayor, debes usar al menos dos sps que son
> sp_xml_preparedocument,
> sp_xml_removedocument y la funcion OPENXML.
>
> Aqui posteo un ejemplo, el cual corri un x numero de veces y como
> promedio
> el metodo uno obtuvo un tiempo mas bajo. Esto no dice nada, se deben
> hacer
> pruebas antes de tomar una decision y si obtener un mejor tiempo, en el
> order
> de las milesimas de segundo o segundos, no es importante para tu
> sistema
> entonces escoje la que mejor te convenga pero si ganar un milisegundo
> es
> importante para tu aplicacion entonces usar xml para simular un arreglo
> unidimensional en t-sql no es la opcion optima.
>
> use northwind
> go
>
> select
> identity(int, 1, 1) as number
> into
> dbo.number
> from
> sysobjects as a
> cross join
> sysobjects as b
> go
>
> alter table dbo.number
> add constraint pk_number primary key clustered (number)
> go
>
> create function dbo.inline_split_me (
> @param varchar(7998)
> )
> returns table
> as
> RETURN(
> select
> substring(',' + @param + ',', Number + 1,
> charindex(',', ',' + @param + ',', Number + 1) -
> Number
> - 1
> ) as Value
> from
> dbo.Number
> where
> Number <= len(',' + @param + ',') - 1
> AND substring(',' + @param + ',', Number, 1) = ','
> )
> go
>
> declare @sd datetime
> declare @ed datetime
> declare @s varchar(7998)
> declare @doc varchar(7998)
> declare @idoc int
>
> set @s >> > '10250,10893,10937,10946,10392,10260,10378,10879,11008,11045,10715,11031,11059'
> set @doc = '
> <ROOT>
> <Order OrderID="10250"/>
> <Order OrderID="10893"/>
> <Order OrderID="10937"/>
> <Order OrderID="10946"/>
> <Order OrderID="10392"/>
> <Order OrderID="10260"/>
> <Order OrderID="10378"/>
> <Order OrderID="10879"/>
> <Order OrderID="11008"/>
> <Order OrderID="11045"/>
> <Order OrderID="10715"/>
> <Order OrderID="11031"/>
> <Order OrderID="11059"/>
> </ROOT>'
>
> dbcc freeproccache
> dbcc dropcleanbuffers
>
> set @sd = getdate()
>
> select
> oh.orderid,
> oh.customerid,
> oh.orderdate
> from
> dbo.orders as oh
> inner join
> dbo.inline_split_me(@s) as a
> on oh.orderid = a.value
>
> set @ed = getdate()
>
> select datediff(millisecond, @sd, @ed)
>
> dbcc freeproccache
> dbcc dropcleanbuffers
>
> set @sd = getdate()
>
> exec sp_xml_preparedocument @idoc OUTPUT, @doc
>
> select
> oh.orderid,
> oh.customerid,
> oh.orderdate
> from
> dbo.orders as oh
> inner join
> openxml(@idoc, '/ROOT/Order', 1)
> with (OrderID int) as a
> on oh.orderid = a.orderid
>
> exec sp_xml_removedocument @idoc
>
> set @ed = getdate()
>
> select datediff(millisecond, @sd, @ed)
> go
>
> drop function inline_split_me
> go
>
> drop table dbo.number
> go
>
>
> Saludos,
>
>
> AMB
>
>
> "Maxi" wrote:
>
>> Ale, lo lei el articulo pero a ver: las otras alternativas no me
>> parecen
>> muy buenas que digamos :S, te comento que estoy usando XML con grandes
>> datos
>> y funciona muy pero muy rapído de verdad. La ventaja a xml que le veo
>> son
>> muchas
>>
>> 1) Usas un formato standard y aislas mucho el SP's
>> 2) La performance como te indique no se ve casi nada afectada, yo como
>> te
>> dije lo uso mucho y en soft con muchas transacciones en un sistemas
>> ERP
>> 3) Es muy simple de usar
>> 4) Es mucho mas seguro que usar SQL dinamico ;-)
>> 5) Dejas todo bien armadito para sql2005 sin mayores cambios
>>
>> De todas maneras agradesco tu articulo, pero como te indique yo uso
>> XMl
>> en
>> sql desde hace un rato largo en sistemas criticos y la verdad que
>> hasta
>> el
>> momento me parece la mejor solucion a pasar datos Array a un Sp's
>>
>>
>>
>> Maxi - Buenos Aires - Argentina
>> Desarrollador 3 Estrellas
>>
>> Msn_messager:
>> mail: Maxi.da[arroba]gmail.com
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Maxi,
>> >
>> > Te invito a que leas el articulo ligado al link posteado. En el
>> > encontraras
>> > una muy buena explicacion sobre este tema, incluyendo tablas de
>> > comparacion
>> > entre los diferentes metodos.
>> >
>> >
>> > AMB
>> >
>> > "Maxi" wrote:
>> >
>> >> Hola, porque dices q no es optima, mira yo lo uso mucho y es muy
>> >> optima!!
>> >> en
>> >> que te basas o que experiencias has tenido con esto para indicar q
>> >> no
>> >> es
>> >> optima?
>> >>
>> >>
>> >> Maxi - Buenos Aires - Argentina
>> >> Desarrollador 3 Estrellas
>> >>
>> >> Msn_messager:
>> >> mail: Maxi.da[arroba]gmail.com
>> >>
>> >> "Alejandro Mesa" escribió
>> >> en
>> >> el
>> >> mensaje news:
>> >> > Nicolas Ibarra Salazar,
>> >> >
>> >> > Como indico Maxi, pudieras pasar los valores en un documento xml
>> >> > como
>> >> > parametro de entrada a un procedimiento almacenado. Esta opcion
>> >> > no
>> >> > es
>> >> > la
>> >> > mas
>> >> > optima, al menos en sql server 2000. Existen otras formas de
>> >> > simular
>> >> > arreglos
>> >> > en t-sql. Aca te paso un link donde podras leer sobre las
>> >> > multiples
>> >> > opciones
>> >> > que existen para hacer esto en sql server.
>> >> >
>> >> > Arrays and Lists in SQL Server
>> >> > http://www.sommarskog.se/arrays-in-sql.html
>> >> >
>> >> >
>> >> > AMB
>> >> >
>> >> > "Nicolas Ibarra Salazar" wrote:
>> >> >
>> >> >> En una SELECT, cómo hago para pasarle más de un valor
>> >> >> proveniente
>> >> >> de
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida