2007 Sep 07 12:05 PM
Hi,
I'm working on a program that uses DDF logical database to list accounting documents. In order to do this, we use three get sentences to loop into KNB1, BSID and BKPF tables.
It's something like that:
GET bkpf.
gjahr is a range with several values
CHECK bkpf-gjahr IN gjahr.
checta is a range with several values
CHECK bkpf-blart IN checta. "1
GET bseg.
CHECK bseg-bschl EQ '01' OR bseg-bschl EQ '11' OR "2
bseg-bschl EQ '12' OR bseg-bschl EQ '02'.
GET gseg.
PERFORM list_document.
But my problem with this code is that it takes too much time to generate the report. Doing some performance analysis on execution, I've determined that the problem is with the access to tables of logical database (the "get" sentences).
So I need to improve report performance, but I don't know how can I do this, maybe if the get returns only the fields I need for execution instead of all table fields runtime would be better, but I'm not very sure if this is possible.
Another option could be changing GET sentences for SELECT, but looking into LDB code I see that as well as hard to change probably it will be useless.
So any information about LDB optimization, or how to improve this kind of reports would be very appreciated.
Thanks in advance
Best regards
Hi,
I'm working on a program that uses DDF logical database to list accounting documents. In order to do this, we use three get sentences to loop into KNB1, BSID and BKPF tables.
It's something like that:
GET bkpf.
gjahr is a range with several values
CHECK bkpf-gjahr IN gjahr.
checta is a range with several values
CHECK bkpf-blart IN checta. "1
GET bseg.
CHECK bseg-bschl EQ '01' OR bseg-bschl EQ '11' OR "2
bseg-bschl EQ '12' OR bseg-bschl EQ '02'.
GET gseg.
PERFORM list_document.
But my problem with this code is that it takes too much time to generate the report. Doing some performance analysis on execution, I've determined that the problem is with the access to tables of logical database (the "get" sentences).
So I need to improve report performance, but I don't know how can I do this, maybe if the get returns only the fields I need for execution instead of all table fields runtime would be better, but I'm not very sure if this is possible.
Another option could be changing GET sentences for SELECT, but looking into LDB code I see that as well as hard to change probably it will be useless.
So any information about LDB optimization, or how to improve this kind of reports would be very appreciated.
Thanks in advance
Best regards
2007 Sep 07 12:14 PM
When i read your report, i think that you should give the selection to the LDB and not use check after the GET, your program GET all records (with other selections) and reject some records.
Try to use LDB selections on BKPF, and not specific selections :
e.g. : Use DD_BLART to select document from BSID table and not check BLART after GET BKPF. Use DD_BSCHL also and not check after BSEG.
To find suitable fields, go to SE36 and then click on selection to get the selections of the LDB program (or search "FROM table" in whole program SAPDBDDF)
Yes, use only fields needed in GET instruction.
Regards
2007 Sep 09 8:10 PM
Hi Raymond,
first of all thanks for your answer, as you say it'd be better to use selection screen instead of check sentences, and I'll also use "GET bkpf FIELDS ..." to get only those fields that I need.
I've tested this improvements but I believe that it doesn't decrease too much execution time, so I need to find more solutions to optimize access to logical databases.
For Rob, maybe you're right and using LDB isn't the best solution, but I got this program done and I can't modify its way of retrieving data, only optimize it. To sum up, I can't erase LDB only optimize its execution.
So any help in LDB optimization would be very appreciated.
Thank you very much to both
2007 Sep 10 7:30 AM
I don't think you can get much more optimization, in the LDB (except if you write a news ZDDF optimized logical database program...)
No try to use performance and trace tools to fin the "heaviest consumption" of resources (SE30 and/or ST05)
If LFA1 or BSID are CPU/Time consumers maybe creating an index adapted to your request will have some effects.
Regards
2007 Sep 07 3:07 PM
I wouldn't use logical databases at all. And I wouldn't look at the LDB code to try to figure out what it is doing. Rather, take your requirements and write the program using SELECT statements.
Rob
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |