CLEAR RESULT.
CLEAR W_Req_Date.
READ TABLE Tb_hdr00 WITH KEY Doc_Num = COMM_STRUCTURE-Doc_Num.
IF SY-Subrc = 0.
W_Req_Date = Tb_hdr00-Req_Date.
ELSE.
SELECT SINGLE req_date FROM /bic/aZOH11hdr00
INTO w_req_date
WHERE Doc_Num = COMM_STRUCTURE-Doc_Num.
IF SY-Subrc = 0.
MOVE-CORRESPONDING /bic/aZOH11hdr00 TO Tb_hdr00.
APPEND Tb_hdr00.
ENDIF.
ENDIF.
2 dic 2010
QUIZ: Abap trap...
Miglioramento performances o ....
Iscriviti a:
Commenti sul post (Atom)
Iscriviti agli aggiornamenti del BLOG!
Post
Commenti
3 commenti:
Premesso che lo faccio spesso, e che le performance dipendono pure dal fatto che Tb_hdr00 sia hashed o no...
credo dipenda molto dalla tabella in questione e da come ci accedi.
SAP e/o il database 'sto mestiere lo fanno già dinamicamente, ma appunto per quello ogni tanto rilasciano i buffers per cachare altro.E per l'accesso al database hai comunque un po' di overhead, specie se è remoto.
Se la tabella è grande, male indicizzata e gli accessi sono spaziati direi che è un buon affare, per la classica tabella di 10 righe è una perdita di tempo.
Almeno così mi risulta, mai speso troppo tempo sulle performance issues.
Marcello
dalla select single FROM /bic/aZOH11hdr00 viene letto solo il campo req_date... e poi mosso in Tb_hdr00.... manca il campo Doc_Num che viene usato nella READ TABLE Tb_hdr00
Mi sembra inutile quindi questo "gioco" di tabelle interne per ridurre le letture da DB, se la tabella interna è così fatta male ;)
Oops!
Mi era sfuggito :)
Posta un commento