Abap : Commit and rollback

[Former Member]

Hi experts,

I have experience with another prog. languages - > what was in the block below was done all or nothing

begin work

call function

delete

update

commit work or rollback

i don't have experience with commit and rollback in ABAP.

i have e.g. code below

  * start block

    CALL FUNCTION 'RSDU_TABLE_TRUNCATE'
    EXPORTING
      i_tablnm        = 'table1

    CALL FUNCTION 'RSDRI_ODSO_INSERT'
    EXPORTING
      i_odsobject                 = 'table1

    CALL FUNCTION 'RSDU_TABLE_TRUNCATE'
    EXPORTING
      i_tablnm        = 'table2'

    CALL FUNCTION 'RSDRI_ODSO_INSERT'
    EXPORTING
      i_odsobject                 = 'table2'

    CALL FUNCTION 'RSEC_GENERATE_FROM_ODS'

* end block

please practise example what should i do to all things will be done "together" ( commit ) or nothing ( rollback - situation before running this code ).

( maybe i have to use ENQUEUE or something like this )

I tried something, but only part of the code in block was rollback.

Is possible add into this block internal table and use rollback for them too ?

Thanks in advance

Martin

[Former Member]

Hi,

Create a custom Function module ZCUSTOM and call all the function mdules in that custom function module

and call

CALL FUNCTION ZCUSTOM IN UPDATE TASK......

You can rollback all the changes in same LUW or Save all the changes.

For further info google it on LUW you will get more info

thanks,Chandra

[Former Member]

I don't want to create a new FM, is it possible ?

[juergenbaur]

Call all your mentioned funciton modules and check if sy-subrc eq 0.

if sy-subrc <> 0.

lv_subrc = 4.

endif.

If all your FM's are executed with sy-subrc eq 0. Your lv_subrc is also 0.

You can write:

if lv_subrc eq 0.

commit work and wait.

else.

rollback work.

endif.

br

Jürgen

[Former Member]

The theory is clear, but if i write the code below, i suppose that after rollback will be data in table1 and table2 as before running code, but

in table1 are new data

and table2 is empty ( it seems that rollback has relation only to command before - > insert into table2)

* start block 

    CALL FUNCTION 'RSDU_TABLE_TRUNCATE'
    EXPORTING
      i_tablnm        = 'table1

    CALL FUNCTION 'RSDRI_ODSO_INSERT'
    EXPORTING
      i_odsobject                 = 'table1

    CALL FUNCTION 'RSDU_TABLE_TRUNCATE'
    EXPORTING
      i_tablnm        = 'table2'

    CALL FUNCTION 'RSDRI_ODSO_INSERT'
    EXPORTING
      i_odsobject                 = 'table2'

rollback work

* end block

[Former Member]

Well, a couple of things:

First, you need to check sy-subrc after each FM call. That should tell you if the FM worked as expected.

Second, each of these FMs may or may not be calling a COMMIT or ROLLBACK.

Rob

[Former Member]

it is clear, i should have to check sy-subrc in the future.

But only for my test example, without check of sy-subrc.

i would like to have the "original" data after rollback, what should i do (code) ?

Thanks

[Former Member]

There is at least one COMMIT buried in one of these FMs, so I expect you will have to do this using native SQL.

Rob

[RaymondGiuseppi]

There are even more than one COMMIT, most of those FM call DD_DB_OPERATION inside, this one perform a COMMIT WORK, so no rollback will be allowed.

You could try to perform a SQL trace of your program, to identify DB COMMIT.

Regards
Raymond

[Former Member]

Please example of the code.

I would like to have for my test code always original data after rollback ( it means ALL "block rollback")

Thanks

Martin

[Former Member]

You're not going to be able to do this using these FMs. Like I said - native SQL.

Rob

[Former Member]

Does it mean that i cannot use these FMs as "block" ? I suppose that the similar examples are "frequent" in ABAP. Which solution is suitable for that ?

please give me small example with "native SQL"

Thanks

Martin

[SuhaSaha]

Hello Martin,

What you are trying to achieve is called Bundling of Updates. And the only way of doing it is thorugh -

• Update Function modules - CALL FUNCTION ... IN UPDATE TASK
• Special sub-routines - PERFORM ... ON COMMIT (obsolete)

You can try to wrap these standard FMs inside a custom Update function module which ensures te atomicity of the transaction.

BR,

Suhas

[Former Member]

Please check the keyword documentation for EXEC SQL.

Rob