In Debug it works but not in standard running ?

[mark_dean]

Hi guys,

We have a situation where we are running a database update but with a user that is assigned authorisation for running of that job only.

It is all working ok except with the creation of spurious 'red' SLG1 logs.

In the program I use the FM BAL_DB_SEARCH to get the SLG1 logs I want to delete and this works fine.

Then I do a COMMIT WORK AND WAIT.

I then run the FM BAL_DB_DELETE with the parameter I_with_commit_work = abap_true based on the logs I selected above.

The problem is I do not delete all of the logs that are selected by the BAL_DB_SEARCH.

When I debug I look at all of the SLG1 logs that the BAL_DB_SEARCH retrieved and the BAL_DB_DELETE works fine.

I put the above in a DO. loop with a COMMIT WORK AND WAIT and also another WAIT UP TO 1 SECONDS but still I get a remaining un deleted log.

The above works perfectly if I enter the program debugging via SM50 (Infinite loop) or if I debug one of the above Function modules with a FM Breakpoint.

Can anyone help me here.

I have looked at ST05 trace and I see a COMMIT CONNECTION default gets actioned so I have tried this in my ABAP to no avail.

Have also tried the FM DB_COMMIT with no avail.

Thanks

Mark

[Sandra_Rossi]

According to what you said, your pseudo code is:

1. WHILE condition.
2.   CALL FUNCTION 'BAL_DB_SEARCH' ...
3.   COMMIT WORK AND WAIT.
4.   CALL FUNCTION 'BAL_DB_DELETE' ...
5.   WAIT UP TO 1 SECONDS.
6. ENDWHILE.

Really, don't you see the problem?

Update: to say things explicitly, COMMIT WORK (AND WAIT) must be done after the deletion, and WAIT UP TO 1 SECONDS is useless (based on your information).

[Softwaris]

Although I agree with sandra.rossi here that you might want to check your initial code first, did you try playing around with the import parameters of BAL_DB_DELETE? There is also a I_IN_UPDATE_TASK parameter there that you might want to check out. And why doing a explicit commit work while doing that again in BAL_DB_DELETE thru parameter I_WITH_COMMIT_WORK? Because your plan works in debug-mode kinda tells me your messing with combining SAP LUW's because of your explicit commit work in combination with wait up to 1 second (although I'm not an expert in SAP LUW's). So, what if you get rid of the explicit commit and let SAP handle the database commit itself?

[babu_gavi]

Hi Mark,

try with below code by improving waiting seconds

WHILEcondition.

CALLFUNCTION'BAL_DB_SEARCH'...

COMMIT WORK AND WAIT upto 2 seconds.

CALLFUNCTION'BAL_DB_DELETE'...

WAITUPTO 2 SECONDS.

ENDWHILE.

[Softwaris]

You sure COMMIT WORK AND WAIT upto 2seconds is a valid construct?

[dev_parbutteea]

You really asking him to do a commit before the delete !!

[mark_dean]

Ok guys thanks.

Before I search for the logs I want to delete I must make sure that all the logs have been committed to the database.

Therefore, before my SLG1 log search and delete process I am calling the FM DB_COMMIT in the same ABAP program (as the below code).

I then have a DO LOOP TO SEARCH for logs and if found to delete them, and I do this loop 2 times with a commit after the delete.

However, a red log still exists after the standard process above is run. Again, when in debug it works properly.

When debugging the code with an infinite loop after the SLG1 Search process I saw that (in debug) that the search process retrieved All of the logs I wanted to delete.

Therefore, before it even knows it is going into debug I am filling an itab with all the logs I want to delete. I then then call the log delete process with all of the contents in this itab.

It is as if the search process reads the records from the database (i.e. SLG1 tables) and also from somewhere else (buffer ??) .

To be honest guys I am foxed at the moment. Any ideas please ?

Thanks

Mark

[Sandra_Rossi]

Please use the COMMENT button for comments, questions, adding details, etc., ANSWER is only to propose a solution, dixit SAP text at the right of the answer area: "Before answering You should only submit an answer when you are proposing a solution to the poster's problem"

[Sandra_Rossi]

You say that your code should delete logs (I agree, BAL_DB_DELETE deletes logs) and some logs are not deleted. I know 2 possibilities: either some logs are already locked, or a BAL_DBDEL_<logobject> function module exists which prevents the log from being deleted.

As you say it works if you wait a little bit via debug, then it's probably a lock which is removed asynchronously. Add a WAIT UP TO 10 SECONDS before your "DO" loop, to make sure that it's the cause, and then tell us the context so that we can help you (I can just say that you placed your custom code in the wrong place).

[FredericGirod]

WAIT UP TO xx SECONDS is a sooooo bad idea, I cannot understand why developpers used that.

So OK, you will find 2 seconds works in your case, it is nice, the test is OK. And ?? you will pass to Integration/Quality system and the number of seconds should be 2.34 ... so you correct it ... and .. in production it will be sometimes 1.234 sec sometimes 4.567 and your program will work sometimes

it is definitively not serious to have a program working 'sometimes'

if there is no technical solution, there must be a functional solution (change the process)