Discussion :

[Drben]

Bonjour @ tous,

Après quelques recherches et pas mal de temps, j'ai enfin réussi à écrire un programme d'extraction de table générique.

Mon code est le suivant :

--------------------------------
PARAMETERS : p_tabl(10) TYPE c. " Nom de la table en dynamique

* Variable :
DATA : line(60000) TYPE c.

* Fields-Symbols :
FIELD-SYMBOLS <f> TYPE ANY.
DATA: count TYPE i.
FIELD-SYMBOLS <f1> TYPE ANY.

* Requete et affichage :
SELECT * FROM (p_tabl) INTO line.
ASSIGN line TO <f> CASTING TYPE (p_tabl).
count = 1.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE <f> TO <f1>.
IF sy-subrc = 0.
* IF NOT <f1> IS INITIAL.
WRITE: <f1>,';'. " Le champs d'index count + le séparateur
* ELSE.
* WRITE: '!',';'. " Pour voir les colonnes vides
* ENDIF.

count = count + 1. " Incrémentation du count
ELSE.
WRITE : /. " Saut de ligne fin d'enregistrement
EXIT.
ENDIF.
ENDDO.
ENDSELECT.
--------------------------------

Cela marche pour la majorité des tables que j'ai à extraire, mais j'ai le message d'erreur ASSIGN_BASE_WRONG_ALIGNMENT pour la table BSAK, erreur signalée en rouge sur le code.

Quelqu'un a t-il une idée ?

[Celdrøn]

Salut,

Je crois qu'il faut plutôt faire :
ASSIGN ('LINE') TO <f> CASTING TYPE (p_tabl).

Voila.

PS : SELECT. [...]. ENDSELECT.

[Drben]

Cela ne change rien de mettre LINE entre parenthèse et quote.

Je précise que cela marche pour la majorité de mes tables.

Cela déconne que pour une minorité d'entre elles.

L'érreur complete est :

ASSIGN_BASE_WRONG_ALIGNMENT: The alignment of the field f is insufficient for the type of the field symbol.

Quelqu'un a déja rencontré le problême ?

[Drben]

UP !

Personne n'a d'idées pour cette erreur ?

[Celdrøn]

Salut,

Bah, moi je ne peux pas tester ton code, il n'est pas compatible Unicode.
Et puis secondo, j'ai pas envie de débugger un SELECT. [...] ENDSELECT., si c'est pour que le débugger me crash à la tronche... c'est pas la peine.

Sinon, j'ai un exemple qui marche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
*- Données globales
*-- Table internes
DATA : t_dyntab TYPE TABLE OF dntab,
       t_fcat TYPE lvc_t_fcat,
*-- Structure de table
       s_fcat TYPE lvc_s_fcat,
       s_dyntab LIKE LINE OF t_dyntab,
*-- Pointeur (Références)
       o_reftab TYPE REF TO data.

*-- Field symbols
FIELD-SYMBOLS : <t_tab>  TYPE table,
                <s_tab> TYPE ANY,
                <field>  TYPE ANY.


*- Sélection
PARAMETERS p_tabnam TYPE dntab-tabname 
                    DEFAULT 'SPFLI'. "Nom de table db

START-OF-SELECTION.

*Création de la table interne
*Récupération de la structure de la table DB
  CALL FUNCTION 'NAMETAB_GET'
    EXPORTING
      langu   = sy-langu
      tabname = p_tabnam
    TABLES
      nametab = t_dyntab. "Contient la liste des champs

*Création du field catalog correspondant à la structure de la table
  LOOP AT t_dyntab INTO s_dyntab.

    s_fcat-fieldname = s_dyntab-fieldname.
    s_fcat-ref_field = s_dyntab-fieldname.
    s_fcat-ref_table = s_dyntab-tabname.

    APPEND s_fcat TO t_fcat .

  ENDLOOP. "AT t_dyntab INTO s_dyntab.

*Création d'une référence (pointeur) sur la table interne
  CALL METHOD cl_alv_table_create=>create_dynamic_table
    EXPORTING
      it_fieldcatalog = t_fcat
    IMPORTING
      ep_table        = o_reftab.

*Référencement du pointeur sur la table interne
  ASSIGN o_reftab->* TO <t_tab>.

  CHECK sy-subrc IS INITIAL.

*Sélection des données.
  SELECT * FROM (p_tabnam)
    INTO CORRESPONDING FIELDS OF TABLE <t_tab>
    UP TO 25 ROWS. "(test = récup les 25 1ère lignes de SPFLI)

*- Affichage brut pour le test...
* Pour une récupération des infos plus précise, utiliser le ASSIGN
* COMPONENT ... OF STRUCTURE ...
  LOOP AT <t_tab> ASSIGNING <s_tab>.

    DO.

      ASSIGN COMPONENT sy-index OF STRUCTURE <s_tab> TO <field>.

      IF NOT sy-subrc IS INITIAL.

        WRITE :/ ''.
        EXIT.

      ELSE.

        WRITE : <field>.

      ENDIF.

    ENDDO.

  ENDLOOP. "AT <t_tab> ASSIGNING <s_tab>.

Nota : Je n'en suis pas l'auteur, mais je ne pense pas faire une bourde en partageant l'exemple.

Avec moi ça marche nickel. ^_^
Essaies de t'en inspirer.

@++.

[Drben]

Salut,


Et puis secondo, j'ai pas envie de débugger un SELECT. [...] ENDSELECT., si c'est pour que le débugger me crash à la tronche... c'est pas la peine.

Merci pour ce code, je vais tester ca demain.

Juste par curiosité, c'est quoi le souci avec le SELECT. [...] ENDSELECT ?

[Celdrøn]

Bah, je reconnais que j'ai tendance à être "un peu" chiant avec les SELECT. [...]ENDSELECT. car j'ai dû un jour débugger un code fait par le client rempli de ce genre d'instructions et pire, des SELECT. [...]ENDSELECT. imbriqué et il suffisait que je passe à l'occurence suivante pour que le débugger perde les pédale et fasse un beau dump, bref pour un truc qui aurait du me prendre la matinée, j'y ai passé la journée, voire 2 jours, et j'en ai laissé des plumes en prime.

Donc ce n'est pas contre toi personnellement t'inquètes pas, mais c'est que ça m'a traumatisé.

Sinon, pour expliquer les gros défauts de cette instruction :
- En débug, ça peut générer des DUMP à cause que le débugger se perd dans les index,
- Coté performance temporelle, c'est l'une des instructions qui consomme le plus de temps selon la masse de données à traiter, il faut savoir que cette instruction va requêter la base autant de fois qu'il y a d'occurences trouvées.
Sachant que le temps de récupération des données est de l'ordre de la ms, on peut imaginer le temps que ça peut mettre.

La bonne pratique à adopter est de charger toutes les occurences en mémoire, c'est à dire de stocker les données dans une table interne ce qui va donc ne faire qu'une seule requête en tout pour tout récupérer. Ensuite les traitements à faire avec les données seront fait à partir de la table interne et la récupération des données mémoire est de l'ordre de la µs, c'est à dire 1000 fois plus rapide.

Quand y'a pas beaucoup de données à traiter, ça reste tolérable... pour des traitements de masse c'est inacceptable.
Pour donner un exemple, un programme qui tournait en 4h, donc du bien lourd, a fini par tourner en 15min après optimisation.

Si tu consultes les bonnes pratiques ABAP tu verras que le SELECT. ENDSELECT. met largement plus de temps.

La preuve en image :


Et cela pour seulement 283 entrées.

Fin voila quoi. ^_^