S.O.O ABAP por favor ayuda que paso ?

Err.tmpo.ejec. TIME_OUT
Fecha y hora 15.01.2010 15:22:00



Texto breve
Time limit exceeded.



¿Qué ha sucedido?
The program "ZPRO_004" has exceeded the maximum permitted runtime without
interruption and has therefore been terminated.




¿Qué puede hacer?
Note down which actions and inputs caused the error.


To process the problem further, contact you SAP system
administrator.

Using Transaction ST22 for ABAP Dump Analysis, you can look
at and manage termination messages, and you can also
keep them for a long time.

Anál.errores
After a specific time, the program is terminated to make the work area
available to other users who may be waiting.
This is to prevent a work area being blocked unnecessarily long by, for
example:
- Endless loops (DO, WHILE, ...),
- Database accesses with a large result set
- Database accesses without a suitable index (full table scan)

The maximum runtime of a program is limited by the system profile
parameter "rdisp/max_wprun_time". The current setting is 3000 seconds. If this
time limit is
exceeded, the system attempts to cancel any running SQL statement or
signals the ABAP processor to stop the running program. Then the system
waits another 60 seconds maximum. If the program is then still active,
the work process is restarted.


Notas para corregir errores
Programs with long runtime should generally be started as background
jobs. If this is not possible, you can increase the system profile
parameter "rdisp/max_wprun_time".

Depending on the cause of the error, you may have to take one of the
following measures:
- Endless loop: Correct program;
- Dataset resulting from database access is too large:
Instead of "SELECT * ... ENDSELECT", use "SELECT * INTO internal table
(for example);
- Database has unsuitable index: Check index generation.

If the error occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:

"TIME_OUT" " "
"ZPRO_004" or "ZPRO_004"
"CARGA_PROVEEDORES"

If you cannot solve the problem yourself and want to send an error
notification to SAP, include the following information:

1. The description of the current problem (short dump)

To save the description, choose "System->List->Save->Local File
(Unconverted)".

2. Corresponding system log

Display the system log by calling transaction SM21.
Restrict the time interval to 10 minutes before and five minutes
after the short dump. Then choose "System->List->Save->Local File
(Unconverted)".

3. If the problem occurs in a problem of your own or a modified SAP
program: The source code of the program
In the editor, choose "Utilities->More
Utilities->Upload/Download->Download".

4. Details about the conditions under which the error occurred or which
actions and input led to the error.


Info posición de cancelación
Termination occurred in the ABAP program "ZPRO_004" - in "CARGA_PROVEEDORES".
The main program was "ZPRO_004 ".

In the source code you have the termination point in line 987
of the (Include) program "ZPRO_004".


957 * --> p1 text
958 * <-- p2 text
959 *----------------------------------------------------------------------*
960 FORM CARGA_PROVEEDORES.
961 *-----------------------------------------------------------------
962 * PROCESO DE OBTENCION DE LA INFORMACION DESDE LA BASE DE DATOS
963 *-----------------------------------------------------------------
964 * Captura de los proveedores :
965 *----------------------------------
966 DATA HAY_COMPRAS.
967 REFRESH S_EKORG.
968 SELECT * FROM T024E WHERE BUKRS IN S_BUKRS.
969 CLEAR S_EKORG.
970 S_EKORG-SIGN = 'I'.
971 S_EKORG-OPTION = 'EQ'.
972 S_EKORG-LOW = T024E-EKORG.
973 APPEND S_EKORG.
974 ENDSELECT.
975
976
977
978
979 SELECT * FROM LFA1 WHERE LIFNR IN S_LIFNR.
980 * AND bukrs IN s_bukrs ORDER BY lifnr.
981 * ON CHANGE OF lfb1-lifnr.
982 SELECT * FROM LFB1 WHERE LIFNR = LFA1-LIFNR
983 AND BUKRS IN S_BUKRS.
984 * check sy-subrc EQ 0.
985 CLEAR HAY_COMPRAS .
986 SELECT * FROM T024E WHERE BUKRS EQ LFB1-BUKRS.
>>> SELECT * FROM LFM1 WHERE LIFNR EQ LFB1-LIFNR
988 AND EKORG EQ T024E-EKORG.989
990
991 CLEAR TABPRO.
992 HAY_COMPRAS = 'X'.
993 *tabpro-banks = ' '. tabpro-bankl = ' '. tabpro-bankn = ' '.
994 SELECT * FROM LFBK WHERE LIFNR = LFM1-LIFNR.
995
996 MOVE-CORRESPONDING LFBK TO TABPRO.
997
998 ENDSELECT.
999
000 MOVE-CORRESPONDING LFM1 TO TABPRO.
001 MOVE-CORRESPONDING LFA1 TO TABPRO.
002 MOVE-CORRESPONDING LFB1 TO TABPRO.
003
004 MOVE TABPRO-NAME1 TO I_TEXTO_DEPURADO.
005 PERFORM DEPURA_TEXTO.
006 MOVE I_TEXTO_DEPURADO TO TABPRO-NAME1.

[kreuzigen]

Que que paso?

Es muy sencillo, tienes anidados 5 selects!!!!!!!

Es el programa mas ineficiente que he visto; debes contactar al autor de este programa para pedirle que optimize este código.

La lógica puede ser correcta, sin embargo esta consumiendo al maximo los recursos del servidor.

Amigo eso quier decir qur al tener una cadena de SELECT

Utiliza mucho recurso en el servidor.-

CUAL PUEDE SER LA SOLUCION SEGUN TU ???

YO TENGO Q REALIZA EL CAMBIO EL AUTOR NO ESTA MAS.

[VLozano]

Lo primero y más importante, mantener la calma.

Primero la parrafada tocapelotas, y en el mensaje siguiente un poco de ayuda.

Cuando consigas eso, si el problema persiste y tienes que preguntar en un foro, intenta poner un asunto al hilo que sea relevante. "Ayuda", "No funciona" y cosas así no sirven de nada. O sí, para que la gente NO entre a leer el mensaje y te deje tirado.

Por ejemplo, este hilo podría "asuntarse": Error de ejecución por Time-out
Entonces, los que crean que pueden echarte un cable, entrarán a leer el hilo, y los que se crean incapaces de hacerlo, y no quieran entrar a aprender nada, podrán ignorar el mensaje y ahorrar tiempo y ancho de banda.

Cuando tengas solventado lo del asunto, empieza con el cuerpo del mensaje. Cosas que ayudan:

1- los mensajes de texto del DUMP ponlos en una cita (tag [ QUOTE]), así distinguiremos el problema del mensaje de error
2- el código en un bloque de código (tag [ CODE]), así distinguiremos el problema del mensaje del código (excepto como en este caso, cuando el código forme parte del mensaje de error)

Y a continuación, la respuesta.

[VLozano]

Y ahora un poco de ayuda específica (el mensaje anterior también es de utilidad, pero más generalizada).

El problema que tienes es que tu programa ("tu" porque ahora está bajo tu responsabilidad) accede a un montón de datos de la forma menos optimizada posible. Y si ha funcionado hasta ahora probablemente ha sido por casualidad.

Opciones:

1- verifica todas las tablas LF* (¿datos de clientes?), busca sus campos comunes (LIFNR probablemente para todas, y luego algunas más específicas) y monta una JOIN (IMPORTANTE: asegúrate de utilizar los índices, o podrías llegar a empeorar el problema)

2- crea secuencas de SQL llamándolas para rellenar tablas internas (INTO TABLE) y encadenadas con sentencias FOR ALL ENTRIES IN (IMPORTANTE: si vas a usar el FAEI, asegúrate antes de que la tabla interna de referencia tiene datos, o bajarás la tabla entera empeorando el problema)

Yo en este caso optaría por la opción 1, pero tomaría esa decisión en base a los datos que contienen MIS tablas LF*.

[VLozano]

Cómo construir la JOIN:
- haz una lista de las SQL en un papel
- para cada SQL, anota los campos del WHERE
- subraya para cada campo WHERE aquellos que apuntan a una SQL anterior
- construye la nueva SQL con tantas JOIN como hagan falta
- Nota: las tablas realmente pequeñas (como la T024E, en MI caso) no las metas en la JOIN, esa lectura no afecta realmente al rendimiento, aunque no sea código optimizado.

Ejemplo: Tu programa (el feo) sería algo así:

[VLozano]

Cómo usar el FOR ALL ENTRIES IN:
En caso de tener muchos datos, y no tener claras las relaciones entre las tablas (pojemplo, campo1 y campo2 no son claves en las otras tablas), el FOR ALL ENTRIES IN es una buena opción.

IMPORTANTE: antes de cada SQL hay que verificar que la anterior ha devuelto datos. Si usas un FAEI con una tabla vacía, el sistema te devolverá LA TABLA ENTERA, independientemente de lo que haya en el WHERE (en serio, de verdad, aunque no te lo puedas creer).

Para el mismo ejemplo anterior, el código FAEI sería:

[VLozano]

Cosas a tener en cuenta:

1- Evita declaraciones tipo TABLES. No representan realmente una mejora, y hacen que el código siga difícil de "leer" para el que no conoce el programa.
2- Pon siempre una lista de los campos a traer en las SQL, ahorrarás memoria, ancho de banda y algunos motores de BBDD lo agradecerán en sus oraciones nocturnas
3- No uses declaraciones de tabla usando el OCCURS o el WITH HEADER LINE, hacen los programas más difíciles de seguir

Esos tres consejos van en contra de la vagancia al teclado, pero un verdadero vago (como yo) los sigue, porque sabe que a la larga te ahorran trabajo.

Cómo:
1- Declara variables t_nombretabla TYPE TABLE OF tabla
2- Usa el "CORRESPONDING" en las sentencias INTO si declaras como en 1, o define las tablas/líneas con un BEGIN o un TYPES
3- Declara dos variables: una t_xx TYPE TABLE OF xx y una w_xx TYPE xx. Los READ, LOOP y demás hazlos INTO w_xx, y siempre sabrás si estás tratando con la tabla (t_xx) o la línea (w_xx)

Son tonteridas de vejete, pero ayudan un montón al que viene detrás.

Suerte.

[bisonye]

Joder Vic, te has quedado a gusto!!

VLozano TIENES UN MAIL PARA ENVIARTE UN CODIGO CON UN ERROR

ES EL MISMO PROGRAMA YA ESTA SOLUCIONADO EL ERROR PERO AHORA

CARGA TODOS LOS ARCHIVOS MENOS UNO..DEJA UNO VACIO SIN DATOS