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

Buena tarde, jóvenes.

Tengo un pequeño detallín con el resultado de un Stored Procedure, el cual tiene un tiempo de procesamiento de más de 15 minutos, un mundo de tiempo que el venerable Delphi 6 que estoy usando para desarrollar la aplicación con un TADOQuery que recoge ése resultado no alcanza a procesar; al grado que inicia el procesamiento de ése SP y la aplicación Delphi "cierra" la conexión, tira el servicio y no muestra el resultado en un reporte, que es la finalidad de ésta aplicación.

¿Alguna idea que me permita ejecutar el Stored Procedure HASTA QUE TERMINE y arroje el resultado deseado al reporte?

jejeje... tenemos la bola de cristal averiada, a ver si los reyes magos nos trae una nueva :D

Mejor sería que nos dieras más datos, por ejemplo, la base de datos que usas, el código del store procedure, el código fuente delphi de cómo lo usas, la tabla o tablas que estás usando, datos adicionales que estimes oportuno para que podamos ayudarte.
Gracias.

Cierto, perdón...

MS SQLServer 2008 R2, el código fuente del SP es ENORME, tanto que el editor de tópicos de ClubDelphi me lo acaba de rechazar.

Código Delphi del llamado:

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;

Si el Stored Procedure se corre por fuera de Delphi, tarda entre 25 y 35 minutos en arrojar resultados..., dentro de Delphi, simplemente nunca termina.

Pues si no podemos mirar nada :confused:

Verifica que tienes índices en los campos involucrados, aunque lo que yo haría es usar el "divide y vencerás" :)
Empieza a "recortar" la sql y ve probando que vaya rápido, si va bien entonces añades algo más y pruebas... y así poco a poco hasta que llegues al "culpable".

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.

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

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

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

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

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. :p

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...:D

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? :confused::confused::confused::eek::eek::eek:
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?.

Debe ser un Windows :p ...

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

Saludos!

Pues entonces "ajo y agua" :confused:.
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.

Windows Server 2003...

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

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