Insert o Addnew

[Neuron_376]

De los SP, estos pierden mucho de su rendimiento cuando lo dejas ejectuando cosas dinamicas, como, a traves de los parametros construir una sentencia para usar EXEC, etc.

Eso les impide tener su 100%, por eso por ejemplo, es preferible crear toda una sentencia select que sabes que es necesaria para el SP, desde fuera en el ASP, y solamente pasarsela para que haga un exec directo de esa cadena que ya formaste.

Bueno, ese es un caso que conozco para que un SP no de su 100% de ventajas sobre una consulta lanzada desde ASP.

Suerte!!

[u_goldman]

Tu dices construir toda tu sentencia desde afuera y pasarsela al SP?

Código:

qry = "una sentecia enoooooorme que me esta dando un dolor de cabeza porque cuelga el servidor"
Set cmd = Server.CreateObject("ADODB.Command")
Set rs = Server.CreateObject("ADODB.Recordset")
cmd.CommandText = "un_sp"
cmd.ActiveConnection = ObjConn
cmd.CommandType = adCmdStoredProc
rs.Open cmd

Y ahora en mi SP

Código:

CREATE PROCEDURE un_test
@sqlSentencia varchar(8000)
AS
  EXEC(@sqlSentencia) 
GO

Con eso seria suficiente para que funcionara? es mejor que hacerla dinamicamente dentro del sp? como la ven?

Salu2,

[Neuron_376]

Si no necesitas regresar parametros, solo necesitas esto:

qry = "un_test " & "una sentecia enoooooorme que me esta dando un dolor de cabeza porque cuelga el servidor'"

Set conn = Server.CreateObject("ADODB.Connection")
conn.execute (qry)

Luego en el procedure si:

CREATE PROCEDURE un_test
@sqlSentencia varchar(8000)
AS
EXEC(@sqlSentencia)
GO

-----------------------------------------

Eso es mejor que:

qry = "un_test " & "[TODOS LOS PARAMETROS]"

Set conn = Server.CreateObject("ADODB.Connection")
conn.execute (qry)

CREATE PROCEDURE un_test [TODOS LOS PARAMETROS]
@sqlSentencia varchar(8000)
AS

//Programacion extensa para construir consulta inmensa.

EXEC(@sqlSentencia)
GO

A eso me refería, que eso mejora el sp cuando sabemos que por executar una consulta dinamica su rendimiento no sera del 100%

Suerte!!

[u_goldman]

OK, deja ver que sale, ahora les cuento por que de mi pregunta

[u_goldman]

Pasando a explicar y despues de 2 dias de estar peleando con una consulta desaforadamente dinamica y mortal...puedo ahora si darles mis resultados:

1. La consulta ni siquiera terminaba cuando era ejecutada por el codigo de VB
2. El mejor performance, lo daba una consulta dinamica desde el stored procedure, el problema era el mantenimiento que se le tiene que dar y las lines interminables que se adicionan cuando se hace una consulta de este tipo
3. Un performance "aceptable" y el ultimo approach fue generar la consulta desde ASP y ejecutarla en el stored procedure, con esto el mantenimiento de dicha consulta no se complica tanto
4. Por alguna extrana razon que desconozco, la consulta generaba datos erroneos cuando un SELECT IN(), no devolvia resultados, por lo tanto tuve que recurrir a condicionar este resultado con T-SQL

Mi consulta dinamica y ademas recursiva :

Código:

IF EXISTS(SELECT DISTINCT j.page_id FROM xref_iGroup_record i INNER JOIN tbl_page j ON i.record_id = j.page_template_id INNER JOIN live_revisions_view k ON j.page_id = k.original_content_id INNER JOIN tbl_template2 l ON k.revision_id = l.template2_id WHERE j.page_id = k.original_content_id AND k.type_id = 1 AND ((l.template2_start_date = '1/1/1900') OR l.template2_start_date < getDate()) AND(( l.template2_end_date = '1/1/1900') OR l.template2_end_date > getDate()) AND j.page_display_bit = '1' AND j.page_parent_id = 1 AND i.table_id = 25 AND i.iGroup_id IN(17) )BEGIN SELECT a.page_id, a.page_template_id, CASE a.page_table_id WHEN 25 THEN (SELECT template2_name FROM tbl_template2 WHERE template2_id = a.page_template_id) WHEN 0 THEN (SELECT template1_name FROM tbl_template1 WHERE template1_id = a.page_template_id) END AS page_name FROM tbl_page a INNER JOIN live_revisions_view b ON a.page_id = b.original_content_id LEFT JOIN tbl_template2 c ON b.revision_id = c.template2_id WHERE a.page_id = b.original_content_id AND b.type_id = 1 AND ((c.template2_start_date = '1/1/1900') OR c.template2_start_date < GetDate()) AND ((c.template2_end_date = '1/1/1900') OR c.template2_end_date > GetDate()) AND a.page_display_bit = '1' AND a.page_template_id NOT IN(SELECT record_id FROM xref_iGroup_record WHERE table_id = 25 AND content_type = 1) AND page_parent_id = 1 OR a.page_id IN(SELECT DISTINCT j.page_id FROM xref_iGroup_record i INNER JOIN tbl_page j ON i.record_id = j.page_template_id INNER JOIN live_revisions_view k ON j.page_id = k.original_content_id INNER JOIN tbl_template2 l ON k.revision_id = l.template2_id WHERE j.page_id = k.original_content_id AND k.type_id = 1 AND ((l.template2_start_date = '1/1/1900') OR l.template2_start_date < getDate()) AND(( l.template2_end_date = '1/1/1900') OR l.template2_end_date > getDate()) AND j.page_display_bit = '1' AND j.page_parent_id = 1 AND i.table_id = 25 AND i.iGroup_id IN(17) ) END ELSE SELECT a.page_id, a.page_template_id, CASE a.page_table_id WHEN 25 THEN (SELECT template2_name FROM tbl_template2 WHERE template2_id = a.page_template_id) WHEN 0 THEN (SELECT template1_name FROM tbl_template1 WHERE template1_id = a.page_template_id) END AS page_name FROM tbl_page a INNER JOIN live_revisions_view b ON a.page_id = b.original_content_id LEFT JOIN tbl_template2 c ON b.revision_id = c.template2_id WHERE a.page_id = b.original_content_id AND b.type_id = 1 AND ((c.template2_start_date = '1/1/1900') OR c.template2_start_date < GetDate()) AND ((c.template2_end_date = '1/1/1900') OR c.template2_end_date > GetDate()) AND a.page_display_bit = '1' AND a.page_template_id NOT IN(SELECT record_id FROM xref_iGroup_record WHERE table_id = 25 AND content_type = 1) AND page_parent_id = 1 ORDER BY page_order

Y el simplisimo stored procedure:

Código:

CREATE PROCEDURE stp_SiteMap
@sqlStatement varchar(8000)
AS
EXEC(@sqlStatement)
GO

Salu2,

[Neuron_376]

Pues si, exactamente eso es lo que decía, que es mejor tener toda la construcción fuera del SP y pasarsela como cadena al SP, porque mejor rendimiento, pero tambien como mencionas, en el ASP tienes mejores funciones (segun yo), para crear una cadena mejor y mas facil.

Suerte!!

[Myakire]

mmmmmmmm, bueno si ya han hecho sus pruebas, pues les creo. Aunque no le encuentro lógica al asunto. ¿Qué diferencia puede tener que el SP tenga definida previamente la consulta o recibirla como parámetro?, ¿Acaso el tener que ir sustituyendo parámetros y verificar su tipo afecta tanto el rendimiento? ......... ¡a documentarse al Internet, Robin!

[u_goldman]

En realidad yo pude apreciar que la mejor solucion era dejarselo todo al SQLeid , pero el problema es que si es una consulta dinamica tu stored procedure se vuelve inmenso, por lo tanto muy dificil de darle mantenimiento, ademas con lo poco que se de T-SQL, pues se complica mas la cosa con eso de andar buscando funciones para hacer una y otra cosa, supongo que la diferencia en este caso particular, es que la consulta se genera en el script de VB, que tiene demasiadas condiciones y concatenaciones, a lo mejor debi haber utilizado el string builder que puso Neuron hace un tiempo, pero bueno, ya esta hecho.

Por cierto, muy util tener esto a la mano

http://msdn.microsoft.com/library/de...eate2_7eeq.asp

Esos son mis $0.02 al momento...

Salu2,