topic Re: Usage of COMMIT WORK AND WAIT in Application Development and Automation Discussions

Usage of COMMIT WORK AND WAIT

Former Member — Mon, 26 Sep 2011 14:46:59 GMT

hi,

i have one problem:

i am archiving a document with function module 'ARCHIV_CREATE_SYNCHRON_META'.

this function works fine but does not give back the unique archiv_id (no import parameter there)

so in the same abap i want to read the table where the above function module has stored the information

about the archiv_id

so far so good, BUT: how can i ensure that the function module already has written into the database ? what if i can't fetch the row because it is not in the database ?

can i use a COMMIT WORK AND WAIT here before i do a select on the table ?

best regards, Martin

Re: Usage of COMMIT WORK AND WAIT

bruce_hartley — Mon, 26 Sep 2011 15:07:13 GMT

Martin;

I have some experience with COMMIT WORK AND WAIT, I'm pretty sure that what you described is what you are going to have to do. I had to do something similar when I called a function module that was storing some things in the database and I had to make sure that they were there before continuting.

Just make sure that you don't put it inside a SELECT loop - I would strongly recommend that you break the program apart in such a way that nothing else is going on.

What I did in a program that had to retrieve what work I did was to break it up into 3 parts:

1 - Read and updates as needed

2 - COMMIT WORK AND WAIT

3 - More work that depended on parts 1 and 2 being done

I hope this helps.

Re: Usage of COMMIT WORK AND WAIT

Former Member — Mon, 26 Sep 2011 15:12:19 GMT

thank you ! well, i have to do the select in 2 loop....endloop. is THIS a problem too when i do a COMMIT WORK AND WAIT in a loop...endloop ?

Re: Usage of COMMIT WORK AND WAIT

Former Member — Mon, 26 Sep 2011 15:46:17 GMT

You can only place the commit after calling the fm ARCHIV_CREATE_SYNCHRON_META, because this fm should update the table with doc id (I suppose TOA01 or something like that)

but probably you don't need it, you need to considere your all program is a single LUW, so all database modifications should be available in the LUW (few days ago this argument was discussed in a post), I mean:

TABLES: <my table>.

<my table>-field_key = 'A'.
INSERT <my_table>.

SELECT SINGLE * 
  FROM <my table>-field_key = 'A'
WRITE SY-SUBRC.

If you try to run this simple code you can note the SY-SUBRC is equal to 0, and there's no COMMIT after INSERT command,

This is as the system gets data from rollback area where the modifications are stored at the moment,

So it the fm ARCHIV_CREATE_SYNCHRON_META doesn't use the COMMIT, probably you can read its modification

Max

Re: Usage of COMMIT WORK AND WAIT

bruce_hartley — Mon, 26 Sep 2011 16:17:02 GMT

Martin;

Do NOT put the COMMIT WORK AND WAIT in any kind of loop. What you want to do is process all of your data, THEN call it. Given the program I have, it works on multiple things and puts into an internal table all the keys to what it updates ( in particular, it's updating MARA - so it has MATNR in it. I didn't include the declarations of wa and it_updated_list, assume that for this example all it has is one field called MATNR.

So here's what I did in a bit more detail in my program - yes I simplified it.

SELECT matnr

INTO wa-matnr

FROM mara

WHERE ( some kind of condition ).

" Do a whole bunch of updates on stuff that relates to materials - code not included here

" Now save this material to be handled later on after the commit and wait

append wa to it_updated_list.

ENDSELECT.

COMMIT WORK AND WAIT.

" Now I can do more things after my commit and wait

LOOP AT it_updated_list INTO wa

" do whatever you need to do here after the commit is done

ENDLOOP.

If you were to call the COMMIT WORK AND WAIT in the SELECT loop, it would bomb on a runtime error