Timing issue with commit (and wait), update and update task

[Former Member]

Hello,

I am having a discussion with SAP concerning a commit and separate luw in an update task.

In the LUW a commit is executed, so the database update is started.

As around 40 tables need to be updated, it could take some time before all update have been processed.

The commit also triggers the LUW in "call .. update task", this luw should read the updated database.

But sometimes it looks like the update task (asynchrone) process overtakes the direct update (the 40 tables).

As this is a correspondence step, the correspondence step fails as the database has not been updated.

One of the SAP specialists states that the update task will only be called after the database has been updated.

I do not agree, can someone help me with extra arguments.

Regards,

Walter van Veen

Example:

CALL function X in UPDATE TASK

UPDATE tables X,Y,Z, etc.

COMMIT

FunctionX

Read tables X,Y,Z,etc.

Create correspondence

Endfunction X

[RaymondGiuseppi]

Seems you only partially use the update task process mixing OPEN-SQL statements and CALL IN UPDATE TASK before the COMMIT WORK (*)

In the COMMIT WORK documentation, the update task are triggered (starts) at 3rd step, and the database commit at 5th step, so database updates from OPEN-SQL statement MAY not be executed if no WAIT option is used in the COMMIT statement, and are NEVER executed before end of update task of high priority (VB1) if the WAIT option is used as 4th (and 5th) step wil only be executed after end of those update tasks.

COMMIT
		3 Update task V1				Update task V2
	1,2	4	5 DB commit		6
COMMIT AND WAIT
		3 Update task V1				Update task V2
	1,2					4	5 DB commit		6

So if your update task FM require database to be updated before their execution (this is kind of misconception) you should perform the update database in an update task FM of high priority called before the other FMs.

Regards,

Raymond

(*) You are not alone...

[Former Member]

Hi

If I've understood you have two separate LUW: the first one for updating and the second one for reading?

The both processes (Updating and Reading) are called in Update Task, so you risk the second process starts when the first one is running and so the tables are not updated yet.....so SAP specialist is right for me.

The step for reading should starts only if the updating step is over...so you should use COMMIT AND WAIT....or insert all two steps in the same LUW

Max

[PeterJonker]

Hi Walter, how are you ?

Did you try COMMIT AND WAIT ?

I assume you did, but in your sample code it is just COMMIT.

And if yes, was there any change in behaviour ?

Otherwise you might put the statement UPDATE tables X,Y,Z, etc. in a perform on commit level 0

and the call function in a perform on commit level 1.

I have no idea if it will work, and maybe you tried this already, but if I read the sap help on "commit" it gave me this idea.

Also how is the update function module you are using defined: Start Immediate / Immediate Start (V1) or start delayed (V2 update), because that influences the behaviour as well.

Peter Jonker

[Former Member]

Hi all, thanks for the quick reply!!

This is NOT custom code, it is SAP standard code.

I think it could wrong when the database is busy updating.

So I was looking for some extra backup to convince SAP, that this could go wrong.

Especially when you have to update around 40 tables!