COMMIT and PERFORMANCE and BAPI UPDATE

[Former Member]

When looping through about 10 000 documents it goes initially quite fast but in the end it is very slow. Is it a basis problem?

Initially it takes about 0,5 sec and in the end each document update takes about 20 sec. In total about 15 hours!

My basis consultant says I should do a commit as seldom as possible. But I want to do it after each document (=a LUW?). I could add a counter and do a commit each 100:th document, but I do not like it.

Pseudo logic.

loop at itab (about 20 000 recs)

..CALL FUNCTION 'BAPI_CTRACDOCUMENT_CHANGE'

..Update of a ZTABLE

..COMMIT WORK.

..GET RUNTIME+display RUNTIME-diff

endloop.

[andreas_mann3]

hi,

mak a update / modify <b>from table af</b><b>ter</b> your loop

A.

[Former Member]

Hi ,

call bapi after every n records(say 100).

this will surely improve performance of code.

loop into table.

at every 100th records

call bapi

commit.

endloop.

rgds,

pravin

[Former Member]

capture all the Documents in one temp.table , after the loop ,try to update ZTABLE.

problem is u are not commiting the work and BAPI call will be in Q.

So try to avoid that one.

Regards

Prabhu

[Former Member]

Sometimes the document is locked and I need to do a rollback of the BAPI-update and the ZTABLE. Very often it least one document is locked. I want to rollback as few docs as possible - nott all of them.

[Former Member]

steps like this .

loop at itab.

CALL ENQUEUE.

CALL BAPI.

COMMIT WORK.

CALL DEQUEUE.

If sy-subrc eq 0.

update.

endloop.

Regards

Prabhu

[Former Member]

I have now done the change and it is much, much faster. The change is a commit at ever 200:th record.

The problem is that I do a commit not when I logically need it (for each document). Instead I do it due to performance-reasons. If something goes wrong I have to roll back not one document - I have to roll back about 100!

[Former Member]

you can use

COMMIT WORK AND WAIT.

or if you are using any BAPI to create/change, use bapi commit

BAPI_TRANSACTION_COMMIT

WAIT = 'X'.

its better to commit work for each document, i guess.

Regards

srikanth.

[naimesh_patel]

Hello,

Put your commit work out of the loop. COMMIT WORK requires to many resorces to execute so, always put it outside the loop.

regards,

Naimesh

[Former Member]

Hi mikael,

1. My basis consultant says I should do a commit as seldom as possible

Yes, they are right.

If we don't do commit,

then,

in the database, the rollback area

goes on increasing, increasing,

and occupies memory and gets slow.

2. I could add a counter and do a commit each 100

Thats the best practical solution.

The figure 100 or 50 or 200 etc,

one has to figure out practically.

regards,

amit m.