|
#1
|
|||
|
|||
Hola Pirri, me interesaria lanzarlo online si no he entendido mal usando el commit work ¿reinicia el valor del time out a 0?, en tal caso te esta porcion de codigo en la que se realizan 90 iteraciones sobre la tabla it_pep_gerencia, cada iteracion tarda aproximadamente 10 segundos, de la manera que me has explicado puedo aumentar el time out pero no me es muy fiable ya que este tiempo puede ser variable, ¿poniendo el comit work al final de la iteracion bastaria? LOOP AT it_pep_gerencia. PERFORM mostrar_indicador USING it_pep_gerencia-posid. CONCATENATE it_pep_gerencia-posid ', ' mpep INTO mpep. PERFORM carga_tipo_val_analitica. PERFORM calcular_totales_analitica. PERFORM carga_tipo_cal_por_analitica. "Debido al nuevo listado que pide Toni Facturacion ctc anual IF p_okabc = 'X' OR p_okcont = 'X'. PERFORM calcular_tot_formatos_analit2. ELSEIF p_fact = 'X'. PERFORM gabar_val_it_analit_fact_anio USING it_pep_gerencia-posid. ENDIF. CLEAR itanaliticaalvacumula. REFRESH itanaliticaalvacumula. COMMIT WORK. ENDLOOP. GRACIAS POR TU ATENCION |
#2
|
||||
|
||||
Yo creo que te serviría pero no sé que hace en los perform de tú programa ¿actualizán la base de datos?.
COMMIT WORK lo que hace es actualizar la base de datos con los datos que tiene en memoría tu proceso, pero si no te da problemas con eso la lógica del tú programa, lo que puedes notar es quizás, que va un poco más lento el proceso al tener que hacer la actualización de la base de datos. En la SM50 puedes comprobar el tiempo de tú programa y si se pone a 0, también este tiempo se pone a 0 cuando haces un debug. Por ejemplo si colocas un break-point cada vez que lo alcanza este tiempo comienza de 0. |
#3
|
|||
|
|||
Los performs del bucle lo que hacen son agregar y modificar registros de la tabla intermedia ¿crees que poniendo COMMIT WORK en cada modify, collect y append se podria solucionar el problema? Gracias |
#4
|
||||
|
||||
Hola,
Al igual que PIRRI, desconozco lo que hacen los performs de tu programa, pero intuyo un elevado número de operaciones con la base de datos (select, insert, etc...) Para mejorar el performance del report, y conseguir que no salta la excepción del TIME-OUT, hay una regla que se debe seguir: Nunca hacer operaciones con la BBDD dentro de un bucle. Conseguirás esto utilizando la sentencia select ... into table, y posteriormente leer de tabla interna y no de la tabla de BBDD. Tengo algún ejemplo, si lo necesitas házmelo saber. Espero haber ayudado. un saludo
__________________
Florentín Navarrete Moya SAP HCM Consultant Mail: Blog: |
#5
|
|||
|
|||
Que tal : Proba con esta funcion SAPGUI_PROGRESS_INDICATOR en lugar del commit. Esto refreca la pantalla con el ya conocido Reloj de SAP.
Saludos. Javier.
__________________
Lo importante no es saber sino saber quien es el que sabe |
#6
|
||||
|
||||
¿no te funciona con uno sólo? ¿Cuanto tarda un sólo registro de it_pep_gerencia? ¿El acceso a la base de datos es rápida? Tienes que considerar también el entorno cuando hay problemas de tiempos, puede que el problema no sea el informe sino otras causas. Podrías estudiar los tiempos del programa para ver donde se está perdiendo tiempo SE30.
|
#7
|
||||
|
||||
El problema estará en que haces selects dentro de loops y eso no es muy recomendable.
Puedes probar bajándote el contenido de las tablas a las que accedes a tablas internas y trabajar con éstas. Otra forma de acelerar búsquedas es usando la instrucción FOR ALL ENTRIES. Espero que te sirva. Saludos, David. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|