El resultado de un Stored Procedure y los tiempos de Delphi.

[[duilioisola]]

No veo el código. Deberás ponerlo entre[ delphi ] y [ /delphi ].

Parece que es:

Código Delphi [-]
with Rprt.adoqryDtsRprt do 
begin 
  Close; 
  SQL.Clear; 
  // 20111010 FEOL Se añade los nuevos parámetros. 
  SQL.Add('SET DATEFORMAT DMY ' + #13 + #10 + 
    DevuelveSP(IntToStr(iIdntfcdrRprt))+' '+ 
    IntToStr(iIdntfcdrRprt)+', '+ 
    QuotedStr(DateToStr(dtetmepckrFchDsd.Date))+', '+ 
    QuotedStr(DateToStr(dtetmepckrFchHst.Date))+', '+ 
    sDsgls+', 0, 0,'+
    sPcntsEgrsds+', 0, '+ 
    sFechaPivote); 
  wsNmbrArchv := SQL.Text; 
  Open; 
end;

• Tu problema puede ser que la transacción tenga un tiempo de timeout "pequeño" para tu requerimiento. (Mira ADOQuery.CommandTimeOut)
• También puede ser que otra transacción colisione con la del listado y genere un error.
• Puede ser también que la cantidad de líneas que devuelve el procedimiento sean demasiadas. Prueba a poner el AdoQuery.CursorLocation = clUseServer.

[TiammatMX]

Empezado por duilioisola

• Tu problema puede ser que la transacción tenga un tiempo de timeout "pequeño" para tu requerimiento. (Mira ADOQuery.CommandTimeOut)

TimeOut a 0, o sea, a infinito. Por ese lado, descartamos el problema.

Empezado por duilioisola

• También puede ser que otra transacción colisione con la del listado y genere un error.

No uso transacciones, son SP's que sólo producen datos.

Empezado por duilioisola

• Puede ser también que la cantidad de líneas que devuelve el procedimiento sean demasiadas. Prueba a poner el AdoQuery.CursorLocation = clUseServer.

Devuelve solamente 88 filas, el más largo de ellos.

[[Chris]]

Estimado Colega, sin ánimo de ofender, sinceramente pienso que un Stored Procedure que dure casi media hora es inaceptable. A cómo ha comentado Casimiro arriba, es mejor que busques como optimizar el tiempo de respuesta de ése procedimiento. Tienes que hacer un análisis exhaustivo de él y ver que índices son necesarios para mejorar su rendiemiento y además debes fijarte que las clausulas SQL sean las óptimas.

Saludos,
Chris

[TiammatMX]

Empezado por Chris

Estimado Colega, sin ánimo de ofender, sinceramente pienso que un Stored Procedure que dure casi media hora es inaceptable...
Chris

Aquí entramos en el terreno del "debería", situación que no es muy agradable. DEBERÍA tardar menos tiempo en ejecutarse, pero por la cantidad de información que procesa (datos de todo el año referentes a estadísticas médicas) ésto no es posible, DEBERÍA ser optimizado, pero el DBA que lo creó ha realizado TODAS las modificaciones técnicas que han sido posibles (y algunas imposibles) y no se ha logrado bajar un segundo el tiempo de respuesta. "Inaceptable" me parece un concepto muy duro.

Empezado por Chris

...A cómo ha comentado Casimiro arriba, es mejor que busques como optimizar el tiempo de respuesta de ése procedimiento. Tienes que hacer un análisis exhaustivo de él y ver que índices son necesarios para mejorar su rendiemiento y además debes fijarte que las clausulas SQL sean las óptimas...

Créeme que el equipo de trabajo del cual soy parte ha buscado una solución a éste problema en particular, especialmente por que corresponde al desarrollo de nuestro cliente principal..., pero en éste momento no hemos encontrado una solución viable, excepto tal vez montar una Cray2 como servidor de datos...

[Casimiro Noteví]

Si das por hecho que se han realizado todas las pruebas posibles, y se han tomado todas las medidas necesarias, y TODOS los métodos posibles para mejorarlos... y das por hecho de que no se puede hacer nada más... ¿entonces por qué preguntas?
Creo que hay que ser más humilde, TODOS tenemos mucho que aprender.
Hay muchísimas cosas que se pueden hacer, suponiendo que sea imposible mejorar más el store procedure y la base de datos, por ejemplo: ¿qué sistema operativo usa el servidor?.

[[Chris]]

Empezado por Casimiro Notevi

por ejemplo: ¿qué sistema operativo usa el servidor?.

Debe ser un Windows ...

Ya en serio, es Windows! El compañero está utilizan SQL Server según me pareció leer.

Saludos!

[Casimiro Noteví]

Pues entonces "ajo y agua" .
No puedes usar un Cray porque windows no funciona ahí.
Si usaras firebird, postgresql, etc. entonces sí puedes instalar un servidor con linux, ya sea uno pequeñito, como en uno de los más potentes mainframes que existen.

[TiammatMX]

Empezado por Casimiro Notevi

...por ejemplo: ¿qué sistema operativo usa el servidor?.

Windows Server 2003...

jejejeje Y lo del Cray2 era broma..., así de desesperados estamos...

[[Chris]]

Empezado por tiammat

Aquí entramos en el terreno del "debería", situación que no es muy agradable. DEBERÍA tardar menos tiempo en ejecutarse, pero por la cantidad de información que procesa (datos de todo el año referentes a estadísticas médicas) ésto no es posible, DEBERÍA ser optimizado, pero el DBA que lo creó ha realizado TODAS las modificaciones técnicas que han sido posibles (y algunas imposibles) y no se ha logrado bajar un segundo el tiempo de respuesta. "Inaceptable" me parece un concepto muy duro.

Fíjate que en términos de optimización:

Código SQL [-]
select * from tabla where cast(campo_entero as string) = '00004'

No es lo mismo que

Código SQL [-]
select id, cliente_nombre from tabla where cast(campo_entero as string) = '00004'

Ni tampoco

Código SQL [-]
select id, cliente_nombre from tabla where campo_entero = 4

No estoy diciendo que tu SP haga este tipo de desperdicio de recursos, sino que hay ciertos comandos SQL que con solo delimitar los campos se optienen incrementos cosiderables. Además, por experiencia propia he visto que la sintaxis influye en ciertos casos. Recuerdo una vez que obtuve un decremento en el tiempo de espera de alrededor de 5,000% optimizando el SQL y agregando algunos índices y quitando algunos no necesarios.

Saludos,
Chris