Potential problems with using a report to run a commit in a separate LUW.

[Former Member]

I am working with a classic Badi within a transaction where I wanted to commit some information to a database before the commit that occurs at the end of the transaction.

Putting a commit point directly inside the BADI caused problems with cursors that were open inside the transaction, so I researched some and discovered that Report Programs can run in a separate database Logical Unit of Work (LUW).

I coded my BADI to call a report which does some database work based on input parameters, and then commits this work to the database before returning control back to the calling BADI function.

Does anyone know of any potential problems from doing this? It seems like a good way to get around restrictions on the use of commit points inside transactions, but I'm not sure if there could be potential undesired effects from doing this.

Has anyone tried this before?

[Former Member]

I am working with a classic Badi within a transaction where I wanted to commit some information to a database before the commit that occurs at the end of the transaction.

Putting a commit point directly inside the BADI caused problems with cursors that were open inside the transaction, so I researched some and discovered that Report Programs can run in a separate database Logical Unit of Work (LUW).

I coded my BADI to call a report which does some database work based on input parameters, and then commits this work to the database before returning control back to the calling BADI function.

Does anyone know of any potential problems from doing this? It seems like a good way to get around restrictions on the use of commit points inside transactions, but I'm not sure if there could be potential undesired effects from doing this.

Has anyone tried this before?

[former_member156446]

there might some redundant data... where your process updates and the new task/LUW also updates the table... apart from that I dont see much problem in using a new task

[MarcinPciak]

Hi Clay,

Yes I did it too. We faced some issues with commit when using fm HR_INFOTYPE_OPERATION . We had to enclose it in separate report which only then let us do physical change in DB.

What is to be noticed here as well is (according to SAP) that DB commit is triggered each time work process is released which happens when:

- system shows dialog message

- RFC call is executed

- new transaction is called

The above however didn't work for me in couple cases, but using separate SAP LUW solves the problem (as you already read). This happens each time:

- new report is called (SUBMIT ...),

- new transaction is called (CALL TRANSACTION ...)

- new asynchoronus RFC call is executed (CALL FUNCTION...STARTING NEW TASK).

This approach works fine for cases I met and had to overcome with such solution. So far we didn't face any issues with that. Works perfectly

Regards

Marcin

[Former Member]

I appreciate the feedback on this. Seems like a nice option to keep in mind.