Consultas muy largas al hacer item.add e item.getitembyid

Hola a todos:
Estamos teniendo un problema extraño de rendimiento con sharepoint, nos
gustaría saber si a alguien le ha pasado y si le ha encontrado solución.

El problema viene al acceder por el modelo de objetos a un elemento de una
lista o al añadir uno nuevo, con las sentencias:

myItem = myWeb.Lists("Procesos").GetItemById(IdProceso)
myItem = myWeb.Lists("Historico Procesos").Items.Add

respectivamente.

El problema es que justo al pasar por esa línea de código, en una traza
puesta en el sql nos sale una consulta que en el primer caso tarda un sg y
pico, pero en el segundo en ocasiones pasa de 10 sg.

La lista historico procesos tiene 8768 elementos, y el problema es que
para hacer un item.add o getitembyid ejecuta esta consulta que devuelve todos
los elementos...

Alguna idea de como mejorar esto?

Aquí os dejo también la consulta que ejecuta, por si os es familiar a
alguno.

Muchas gracias por adelantado.

Un saludo


EXEC sp_executesql N'SELECT TOP 2147483648 t2.[tp_Title] AS
c18c1,UserData.[ntext2],UserData.tp_Created,UserData.[tp_ID],t1.[tp_Title] AS
c17c1,UserData.[tp_Version],UserData.[tp_InstanceID],UserData.[tp_ItemOrder],UserData.[tp_GUID],UserData.tp_ID,UserData.[nvarchar1],UserData.[tp_Created],UserData.[tp_Author],t2.[tp_Email]
AS
c18c2,UserData.[tp_Editor],UserData.[tp_ModerationStatus],UserData.tp_Version,t1.[tp_Email] AS
c17c2,UserData.[tp_HasAttachment],UserData.[ntext1],UserData.[nvarchar2],t3.[tp_ID] AS
c19c20,UserData.[int1],UserData.[tp_Modified],UserData.[nvarchar3] FROM
UserData LEFT OUTER JOIN UserInfo AS t1 ON
(UserData.[tp_Author]=t1.[tp_ID] AND t1.tp_SiteId = @L1 AND
UserData.tp_ListId = @L2) LEFT OUTER JOIN UserInfo AS t2 ON
(UserData.[tp_Editor]=t2.[tp_ID] AND t2.tp_SiteId = @L1 AND
UserData.tp_ListId = @L2) LEFT OUTER JOIN UserData AS t3 ON
(UserData.[int1]=t3.[tp_ID] AND t3.tp_ListId = @L3 AND UserData.tp_ListId =
@L2) WHERE UserData.tp_ListID=@L2 ORDER BY UserData.[tp_ID]
Asc', N'@L1 uniqueidentifier,@L2 uniqueidentifier,@L3 uniqueidentifier',
'2B6375B9-AF34-4633-BB8E-8A4AC9999AB0','14530077-46F0-469A-BD6F-02BBE4BF3C14','6CA146E4-5CE9-4732-85A5-1E6A045159C5'

Hola,
Yo miraria primero que el (los) servidor(es) de SQL esten rindiendo sin
problemas (que el CPU no se vaya al 100%, suficiente RAM y disco duro). Las
Bases de Datos de SharePoint son ajustadas al maximo para el mas alto
rendimiento, y cualquier cambio puede tener efectos colaterales
imprevisibles. Microsoft no proporciona informacion al respecto, y si
"arreglas" algo por un lado, te puedes cargar el rendimiento por otro.
Saludes,
Gustavo
http://www.gavd.net/servers/default.aspx
http://geeks.ms/blogs/gvelez/


"Fonsi" wrote:

> Hola a todos:
> Estamos teniendo un problema extraño de rendimiento con sharepoint, nos
> gustaría saber si a alguien le ha pasado y si le ha encontrado solución.
>
> El problema viene al acceder por el modelo de objetos a un elemento de una
> lista o al añadir uno nuevo, con las sentencias:
>
> myItem = myWeb.Lists("Procesos").GetItemById(IdProceso)
> myItem = myWeb.Lists("Historico Procesos").Items.Add
>
> respectivamente.
>
> El problema es que justo al pasar por esa línea de código, en una traza
> puesta en el sql nos sale una consulta que en el primer caso tarda un sg y
> pico, pero en el segundo en ocasiones pasa de 10 sg.
>
> La lista historico procesos tiene 8768 elementos, y el problema es que
> para hacer un item.add o getitembyid ejecuta esta consulta que devuelve todos
> los elementos...
>
> Alguna idea de como mejorar esto?
>
> Aquí os dejo también la consulta que ejecuta, por si os es familiar a
> alguno.
>
> Muchas gracias por adelantado.
>
> Un saludo
>
>
> EXEC sp_executesql N'SELECT TOP 2147483648 t2.[tp_Title] AS
> c18c1,UserData.[ntext2],UserData.tp_Created,UserData.[tp_ID],t1.[tp_Title] AS
> c17c1,UserData.[tp_Version],UserData.[tp_InstanceID],UserData.[tp_ItemOrder],UserData.[tp_GUID],UserData.tp_ID,UserData.[nvarchar1],UserData.[tp_Created],UserData.[tp_Author],t2.[tp_Email]
> AS
> c18c2,UserData.[tp_Editor],UserData.[tp_ModerationStatus],UserData.tp_Version,t1.[tp_Email] AS
> c17c2,UserData.[tp_HasAttachment],UserData.[ntext1],UserData.[nvarchar2],t3.[tp_ID] AS
> c19c20,UserData.[int1],UserData.[tp_Modified],UserData.[nvarchar3] FROM
> UserData LEFT OUTER JOIN UserInfo AS t1 ON
> (UserData.[tp_Author]=t1.[tp_ID] AND t1.tp_SiteId = @L1 AND
> UserData.tp_ListId = @L2) LEFT OUTER JOIN UserInfo AS t2 ON
> (UserData.[tp_Editor]=t2.[tp_ID] AND t2.tp_SiteId = @L1 AND
> UserData.tp_ListId = @L2) LEFT OUTER JOIN UserData AS t3 ON
> (UserData.[int1]=t3.[tp_ID] AND t3.tp_ListId = @L3 AND UserData.tp_ListId =
> @L2) WHERE UserData.tp_ListID=@L2 ORDER BY UserData.[tp_ID]
> Asc', N'@L1 uniqueidentifier,@L2 uniqueidentifier,@L3 uniqueidentifier',
> '2B6375B9-AF34-4633-BB8E-8A4AC9999AB0','14530077-46F0-469A-BD6F-02BBE4BF3C14','6CA146E4-5CE9-4732-85A5-1E6A045159C5'

La duda que nos surge, es por qué para hacer un "Getitembyid" que rellena
un objeto con un sólo item, se ejecuta una consulta que devuelve todas las
filas de la lista.

La respuesta que buscamos es si por tu experiencia conoces alguna otra
forma por el modelo de objetos, o como sea, para poder acceder a un item,
cambiar sus datos, y hacer un update, que haga una consulta con algo tipo
"where tp_id = iditemnuestro".

Hola Gustavo:
Muchas gracias por tu rápida respuesta.

Este problema ocurre en una herramienta que tenemos ya en producción, en
varios clientes y cada uno con servidores de características diferentes,
desde "normalitos" hasta aparatos con 4 procesadores bastante potentes.

El caso es que en todos ellos nos pasa esto en mayor o menor medida (el
los mas gordos esto tarda 2 sg y en los peores.. pues 8 o 10..).

La duda que nos surge, es por qué para hacer un "Getitembyid" que rellena
un objeto con un sólo item, se ejecuta una consulta que devuelve todas las
filas de la lista.

La respuesta que buscamos es si por tu experiencia conoces alguna otra
forma por el modelo de objetos, o como sea, para poder acceder a un item,
cambiar sus datos, y hacer un update, que haga una consulta con algo tipo
"where tp_id = iditemnuestro".

Como es lógico, queríamos evitar tener que acceder nosotros a la base de
datos

Muchas gracias por tu ayuda

"Gustavo" wrote:

> Hola,
> Yo miraria primero que el (los) servidor(es) de SQL esten rindiendo sin
> problemas (que el CPU no se vaya al 100%, suficiente RAM y disco duro). Las
> Bases de Datos de SharePoint son ajustadas al maximo para el mas alto
> rendimiento, y cualquier cambio puede tener efectos colaterales
> imprevisibles. Microsoft no proporciona informacion al respecto, y si
> "arreglas" algo por un lado, te puedes cargar el rendimiento por otro.
> Saludes,
> Gustavo
> http://www.gavd.net/servers/default.aspx
> http://geeks.ms/blogs/gvelez/
>
>
> "Fonsi" wrote:
>
> > Hola a todos:
> > Estamos teniendo un problema extraño de rendimiento con sharepoint, nos
> > gustaría saber si a alguien le ha pasado y si le ha encontrado solución.
> >
> > El problema viene al acceder por el modelo de objetos a un elemento de una
> > lista o al añadir uno nuevo, con las sentencias:
> >
> > myItem = myWeb.Lists("Procesos").GetItemById(IdProceso)
> > myItem = myWeb.Lists("Historico Procesos").Items.Add
> >
> > respectivamente.
> >
> > El problema es que justo al pasar por esa línea de código, en una traza
> > puesta en el sql nos sale una consulta que en el primer caso tarda un sg y
> > pico, pero en el segundo en ocasiones pasa de 10 sg.
> >
> > La lista historico procesos tiene 8768 elementos, y el problema es que
> > para hacer un item.add o getitembyid ejecuta esta consulta que devuelve todos
> > los elementos...
> >
> > Alguna idea de como mejorar esto?
> >
> > Aquí os dejo también la consulta que ejecuta, por si os es familiar a
> > alguno.
> >
> > Muchas gracias por adelantado.
> >
> > Un saludo
> >
> >
> > EXEC sp_executesql N'SELECT TOP 2147483648 t2.[tp_Title] AS
> > c18c1,UserData.[ntext2],UserData.tp_Created,UserData.[tp_ID],t1.[tp_Title] AS
> > c17c1,UserData.[tp_Version],UserData.[tp_InstanceID],UserData.[tp_ItemOrder],UserData.[tp_GUID],UserData.tp_ID,UserData.[nvarchar1],UserData.[tp_Created],UserData.[tp_Author],t2.[tp_Email]
> > AS
> > c18c2,UserData.[tp_Editor],UserData.[tp_ModerationStatus],UserData.tp_Version,t1.[tp_Email] AS
> > c17c2,UserData.[tp_HasAttachment],UserData.[ntext1],UserData.[nvarchar2],t3.[tp_ID] AS
> > c19c20,UserData.[int1],UserData.[tp_Modified],UserData.[nvarchar3] FROM
> > UserData LEFT OUTER JOIN UserInfo AS t1 ON
> > (UserData.[tp_Author]=t1.[tp_ID] AND t1.tp_SiteId = @L1 AND
> > UserData.tp_ListId = @L2) LEFT OUTER JOIN UserInfo AS t2 ON
> > (UserData.[tp_Editor]=t2.[tp_ID] AND t2.tp_SiteId = @L1 AND
> > UserData.tp_ListId = @L2) LEFT OUTER JOIN UserData AS t3 ON
> > (UserData.[int1]=t3.[tp_ID] AND t3.tp_ListId = @L3 AND UserData.tp_ListId =
> > @L2) WHERE UserData.tp_ListID=@L2 ORDER BY UserData.[tp_ID]
> > Asc', N'@L1 uniqueidentifier,@L2 uniqueidentifier,@L3 uniqueidentifier',
> > '2B6375B9-AF34-4633-BB8E-8A4AC9999AB0','14530077-46F0-469A-BD6F-02BBE4BF3C14','6CA146E4-5CE9-4732-85A5-1E6A045159C5'

Hola de nuevo,

> La duda que nos surge, es por qué para hacer un "Getitembyid" que rellena
> un objeto con un sólo item, se ejecuta una consulta que devuelve todas las
> filas de la lista.

Solamente los Dioses en el Wallalla y Microsoft mismo lo saben... aunque
puede ser que los Dioses tampocon lo sepan...

> La respuesta que buscamos es si por tu experiencia conoces alguna otra
> forma por el modelo de objetos, o como sea, para poder acceder a un item,
> cambiar sus datos, y hacer un update, que haga una consulta con algo tipo
> "where tp_id = iditemnuestro".

Gracias por las flores, me estoy sonrojando... Hablando en serio, no, la
verdad es que tienes dos formas para hacer lo que quieres (o tres, pero la
tercera, trabajar directamente desde la BBDD no te la aconsejo): usando el
Modelo de Objetos como lo estas haciendo ahora, o usando los WebServices, que
es lo mismo, pero es diferente... esta ultima no te va a mejorar el
rendimiento, eso te lo aseguro.

Por otra parte, si miras las recomendaciones sobre Listas de Microsoft (las
puedes ver en el articulo
http://www.gavd.net/servers/sharepo...t&itmx , al
final), te estas pasando escandalosamente del limite recomendado de elementos
por Lista, lo que te degrada el rendimiento considerablemente. De pronto
tienes que mirar si el posible organizar los elementos en diferentes Listas,
o usar una BBDD externa.

Suerte,
Gustavo
http://www.gavd.net/servers/default.aspx
http://geeks.ms/blogs/gvelez/


"Fonsi" wrote:

> Hola Gustavo:
> Muchas gracias por tu rápida respuesta.
>
> Este problema ocurre en una herramienta que tenemos ya en producción, en
> varios clientes y cada uno con servidores de características diferentes,
> desde "normalitos" hasta aparatos con 4 procesadores bastante potentes.
>
> El caso es que en todos ellos nos pasa esto en mayor o menor medida (el
> los mas gordos esto tarda 2 sg y en los peores.. pues 8 o 10..).
>
> La duda que nos surge, es por qué para hacer un "Getitembyid" que rellena
> un objeto con un sólo item, se ejecuta una consulta que devuelve todas las
> filas de la lista.
>
> La respuesta que buscamos es si por tu experiencia conoces alguna otra
> forma por el modelo de objetos, o como sea, para poder acceder a un item,
> cambiar sus datos, y hacer un update, que haga una consulta con algo tipo
> "where tp_id = iditemnuestro".
>
> Como es lógico, queríamos evitar tener que acceder nosotros a la base de
> datos
>
> Muchas gracias por tu ayuda
>
> "Gustavo" wrote:
>
> > Hola,
> > Yo miraria primero que el (los) servidor(es) de SQL esten rindiendo sin
> > problemas (que el CPU no se vaya al 100%, suficiente RAM y disco duro). Las
> > Bases de Datos de SharePoint son ajustadas al maximo para el mas alto
> > rendimiento, y cualquier cambio puede tener efectos colaterales
> > imprevisibles. Microsoft no proporciona informacion al respecto, y si
> > "arreglas" algo por un lado, te puedes cargar el rendimiento por otro.
> > Saludes,
> > Gustavo
> > http://www.gavd.net/servers/default.aspx
> > http://geeks.ms/blogs/gvelez/
> >
> >
> > "Fonsi" wrote:
> >
> > > Hola a todos:
> > > Estamos teniendo un problema extraño de rendimiento con sharepoint, nos
> > > gustaría saber si a alguien le ha pasado y si le ha encontrado solución.
> > >
> > > El problema viene al acceder por el modelo de objetos a un elemento de una
> > > lista o al añadir uno nuevo, con las sentencias:
> > >
> > > myItem = myWeb.Lists("Procesos").GetItemById(IdProceso)
> > > myItem = myWeb.Lists("Historico Procesos").Items.Add
> > >
> > > respectivamente.
> > >
> > > El problema es que justo al pasar por esa línea de código, en una traza
> > > puesta en el sql nos sale una consulta que en el primer caso tarda un sg y
> > > pico, pero en el segundo en ocasiones pasa de 10 sg.
> > >
> > > La lista historico procesos tiene 8768 elementos, y el problema es que
> > > para hacer un item.add o getitembyid ejecuta esta consulta que devuelve todos
> > > los elementos...
> > >
> > > Alguna idea de como mejorar esto?
> > >
> > > Aquí os dejo también la consulta que ejecuta, por si os es familiar a
> > > alguno.
> > >
> > > Muchas gracias por adelantado.
> > >
> > > Un saludo
> > >
> > >
> > > EXEC sp_executesql N'SELECT TOP 2147483648 t2.[tp_Title] AS
> > > c18c1,UserData.[ntext2],UserData.tp_Created,UserData.[tp_ID],t1.[tp_Title] AS
> > > c17c1,UserData.[tp_Version],UserData.[tp_InstanceID],UserData.[tp_ItemOrder],UserData.[tp_GUID],UserData.tp_ID,UserData.[nvarchar1],UserData.[tp_Created],UserData.[tp_Author],t2.[tp_Email]
> > > AS
> > > c18c2,UserData.[tp_Editor],UserData.[tp_ModerationStatus],UserData.tp_Version,t1.[tp_Email] AS
> > > c17c2,UserData.[tp_HasAttachment],UserData.[ntext1],UserData.[nvarchar2],t3.[tp_ID] AS
> > > c19c20,UserData.[int1],UserData.[tp_Modified],UserData.[nvarchar3] FROM
> > > UserData LEFT OUTER JOIN UserInfo AS t1 ON
> > > (UserData.[tp_Author]=t1.[tp_ID] AND t1.tp_SiteId = @L1 AND
> > > UserData.tp_ListId = @L2) LEFT OUTER JOIN UserInfo AS t2 ON
> > > (UserData.[tp_Editor]=t2.[tp_ID] AND t2.tp_SiteId = @L1 AND
> > > UserData.tp_ListId = @L2) LEFT OUTER JOIN UserData AS t3 ON
> > > (UserData.[int1]=t3.[tp_ID] AND t3.tp_ListId = @L3 AND UserData.tp_ListId =
> > > @L2) WHERE UserData.tp_ListID=@L2 ORDER BY UserData.[tp_ID]
> > > Asc', N'@L1 uniqueidentifier,@L2 uniqueidentifier,@L3 uniqueidentifier',
> > > '2B6375B9-AF34-4633-BB8E-8A4AC9999AB0','14530077-46F0-469A-BD6F-02BBE4BF3C14','6CA146E4-5CE9-4732-85A5-1E6A045159C5'

Muchas gracias por la respuesta.. es justo lo que buscábamos.

Ahora se nos plantea una nueva duda.. en algún sitio se habla de estos
mismos límites en sharepoint 3?

Si estos subieran podría ser una opción ya que estamos comenzando la
migración. De otra forma no tendríamos que plantear un cambio en el diseño de
la aplicación.

Un saludo
Alfonso

"Gustavo" wrote:

> Hola de nuevo,
>
> > La duda que nos surge, es por qué para hacer un "Getitembyid" que rellena
> > un objeto con un sólo item, se ejecuta una consulta que devuelve todas las
> > filas de la lista.
>
> Solamente los Dioses en el Wallalla y Microsoft mismo lo saben... aunque
> puede ser que los Dioses tampocon lo sepan...
>
> > La respuesta que buscamos es si por tu experiencia conoces alguna otra
> > forma por el modelo de objetos, o como sea, para poder acceder a un item,
> > cambiar sus datos, y hacer un update, que haga una consulta con algo tipo
> > "where tp_id = iditemnuestro".
>
> Gracias por las flores, me estoy sonrojando... Hablando en serio, no, la
> verdad es que tienes dos formas para hacer lo que quieres (o tres, pero la
> tercera, trabajar directamente desde la BBDD no te la aconsejo): usando el
> Modelo de Objetos como lo estas haciendo ahora, o usando los WebServices, que
> es lo mismo, pero es diferente... esta ultima no te va a mejorar el
> rendimiento, eso te lo aseguro.
>
> Por otra parte, si miras las recomendaciones sobre Listas de Microsoft (las
> puedes ver en el articulo
> http://www.gavd.net/servers/sharepo...t&itmx , al
> final), te estas pasando escandalosamente del limite recomendado de elementos
> por Lista, lo que te degrada el rendimiento considerablemente. De pronto
> tienes que mirar si el posible organizar los elementos en diferentes Listas,
> o usar una BBDD externa.
>
> Suerte,
> Gustavo
> http://www.gavd.net/servers/default.aspx
> http://geeks.ms/blogs/gvelez/
>
>
> "Fonsi" wrote:
>
> > Hola Gustavo:
> > Muchas gracias por tu rápida respuesta.
> >
> > Este problema ocurre en una herramienta que tenemos ya en producción, en
> > varios clientes y cada uno con servidores de características diferentes,
> > desde "normalitos" hasta aparatos con 4 procesadores bastante potentes.
> >
> > El caso es que en todos ellos nos pasa esto en mayor o menor medida (el
> > los mas gordos esto tarda 2 sg y en los peores.. pues 8 o 10..).
> >
> > La duda que nos surge, es por qué para hacer un "Getitembyid" que rellena
> > un objeto con un sólo item, se ejecuta una consulta que devuelve todas las
> > filas de la lista.
> >
> > La respuesta que buscamos es si por tu experiencia conoces alguna otra
> > forma por el modelo de objetos, o como sea, para poder acceder a un item,
> > cambiar sus datos, y hacer un update, que haga una consulta con algo tipo
> > "where tp_id = iditemnuestro".
> >
> > Como es lógico, queríamos evitar tener que acceder nosotros a la base de
> > datos
> >
> > Muchas gracias por tu ayuda
> >
> > "Gustavo" wrote:
> >
> > > Hola,
> > > Yo miraria primero que el (los) servidor(es) de SQL esten rindiendo sin
> > > problemas (que el CPU no se vaya al 100%, suficiente RAM y disco duro). Las
> > > Bases de Datos de SharePoint son ajustadas al maximo para el mas alto
> > > rendimiento, y cualquier cambio puede tener efectos colaterales
> > > imprevisibles. Microsoft no proporciona informacion al respecto, y si
> > > "arreglas" algo por un lado, te puedes cargar el rendimiento por otro.
> > > Saludes,
> > > Gustavo
> > > http://www.gavd.net/servers/default.aspx
> > > http://geeks.ms/blogs/gvelez/
> > >
> > >
> > > "Fonsi" wrote:
> > >
> > > > Hola a todos:
> > > > Estamos teniendo un problema extraño de rendimiento con sharepoint, nos
> > > > gustaría saber si a alguien le ha pasado y si le ha encontrado solución.
> > > >
> > > > El problema viene al acceder por el modelo de objetos a un elemento de una
> > > > lista o al añadir uno nuevo, con las sentencias:
> > > >
> > > > myItem = myWeb.Lists("Procesos").GetItemById(IdProceso)
> > > > myItem = myWeb.Lists("Historico Procesos").Items.Add
> > > >
> > > > respectivamente.
> > > >
> > > > El problema es que justo al pasar por esa línea de código, en una traza
> > > > puesta en el sql nos sale una consulta que en el primer caso tarda un sg y
> > > > pico, pero en el segundo en ocasiones pasa de 10 sg.
> > > >
> > > > La lista historico procesos tiene 8768 elementos, y el problema es que
> > > > para hacer un item.add o getitembyid ejecuta esta consulta que devuelve todos
> > > > los elementos...
> > > >
> > > > Alguna idea de como mejorar esto?
> > > >
> > > > Aquí os dejo también la consulta que ejecuta, por si os es familiar a
> > > > alguno.
> > > >
> > > > Muchas gracias por adelantado.
> > > >
> > > > Un saludo
> > > >
> > > >
> > > > EXEC sp_executesql N'SELECT TOP 2147483648 t2.[tp_Title] AS
> > > > c18c1,UserData.[ntext2],UserData.tp_Created,UserData.[tp_ID],t1.[tp_Title] AS
> > > > c17c1,UserData.[tp_Version],UserData.[tp_InstanceID],UserData.[tp_ItemOrder],UserData.[tp_GUID],UserData.tp_ID,UserData.[nvarchar1],UserData.[tp_Created],UserData.[tp_Author],t2.[tp_Email]
> > > > AS
> > > > c18c2,UserData.[tp_Editor],UserData.[tp_ModerationStatus],UserData.tp_Version,t1.[tp_Email] AS
> > > > c17c2,UserData.[tp_HasAttachment],UserData.[ntext1],UserData.[nvarchar2],t3.[tp_ID] AS
> > > > c19c20,UserData.[int1],UserData.[tp_Modified],UserData.[nvarchar3] FROM
> > > > UserData LEFT OUTER JOIN UserInfo AS t1 ON
> > > > (UserData.[tp_Author]=t1.[tp_ID] AND t1.tp_SiteId = @L1 AND
> > > > UserData.tp_ListId = @L2) LEFT OUTER JOIN UserInfo AS t2 ON
> > > > (UserData.[tp_Editor]=t2.[tp_ID] AND t2.tp_SiteId = @L1 AND
> > > > UserData.tp_ListId = @L2) LEFT OUTER JOIN UserData AS t3 ON
> > > > (UserData.[int1]=t3.[tp_ID] AND t3.tp_ListId = @L3 AND UserData.tp_ListId =
> > > > @L2) WHERE UserData.tp_ListID=@L2 ORDER BY UserData.[tp_ID]
> > > > Asc', N'@L1 uniqueidentifier,@L2 uniqueidentifier,@L3 uniqueidentifier',
> > > > '2B6375B9-AF34-4633-BB8E-8A4AC9999AB0','14530077-46F0-469A-BD6F-02BBE4BF3C14','6CA146E4-5CE9-4732-85A5-1E6A045159C5'