Hola colegas,
Aquí les traigo una consulta: ¿alguna vez les ha pasado que no han encontrado otra opción que hacer un loop dentro de loop?
El caso es que en las buenas prácticas no se recomienda, y hay una manera de optimizar por medio de index cuando las tablas internas tienen una relación de uno a muchos, por ej. Cabecera - Detalle, pero si no existe este tipo de relación no veo otra opción.
Me gustaría saber qué alternativa han encontrado.
La verdad no estoy seguro si es una mala práctica, habría que investigar un poco más al respecto, si usas el code inspector no lo detecta como un problema de rendimiento, como por ejemplo es el caso de un SELECT dentro de un loop. Al menos yo si lo utilizo y nunca me ha generado problemas de rendimiento en mis desarrollos. Lo que si me han recomendando es utilizar field-symbols para las asignaciones dinámicas:
LOOP AT it_ejemplo ASSIGNING <fs_ejemplo>. "Primer ciclo, que podría ser una tabla de cabecera
LOOP AT it_ejemplo2 ASSIGNING <fs_ejemplo2> "Ciclo anidado, que podría ser una tabla de posiciones
WHERE llave1 = <fs_ejemplo>-llave1.
ASSIGN it_ejemplo3[ llave1 = <fs_ejemplo2>-llave1 ] TO <fs_ejemplo3>. "En lugar del típico Read table, seguimos con la dinámica de usar field-symbols
IF sy-subrc EQ 0.
"Lógica con lectura éxitosa
ENDIF.
ENDLOOP.
ENDLOOP.
Lo anterior es el ejemplo de la estructura que utilizo con ciclos anidados, lecturas de tablas y así, y repito, no he tenido hasta ahora problemas de performance manejándolo de esta forma. Igual si alguien sabe de una alternativa mejor sería bueno saberlo
Espero ser de ayuda, saludos.
Comprendo. He utilizado esta modalidad con los 2 loops, así como el index en el segundo loop para empezar a buscar desde la posición en que se quedó la búsqueda en la segunda tabla. Y funcionan sin problemas.
Entiendo que a veces los estándares de un cliente son más exigentes y ponen restricciones como estas.
Aquí les dejo un código que sirve para recorrer dos tablas con una relación cabecera-detalle, que evita recorrer todos los registros, sino que en la segunda tabla recorre a partir del índice donde se quedó en la iteración anterior.
Ambas tablas deben estar ordenadas por el campo clave.
Espero les sea útil en algún momento.
index = 1.
Loop at it_cab into wa_cab.
Loop at it_det into wa_det from index.
If wa_cab-key <> wa_det-key.
Index = sy-tabix. Exit.
Endif.
Endloop.
Endloop.
Hola,
Mi mejor recomendacion es que uses un parrallel cursor, es un algoritmo muy facil, usa Loop anidados, si es una solucion, pero segun la cantidad de data, puede entrar en una situacion grave de performance.
Recuerda el binary search, debes ordenar previamente.
h_tps://wiki.scn.sap.com/wiki/display/Snippets/ABAP+Code+for+Parallel+Cursor+-+Loop+Processing?original_fqdn=wiki.sdn.sap.com
De igual forma puedes intentar replicarlo con ABAP 7.4 +.
Tengo varios años usando esta tecnica con mucho exito.
Saludos.
Este tema se cerró automáticamente 30 días después de la última publicación. No se permiten nuevas respuestas.