Update/Modify Statement Failing

[Former Member]

Hi All,

Recently we have come across a strange situation where-in the UPDATE/Modify Statement is failing quite often.

Ex:

MODIFY zpp080e FROM gs_zpp080e.

OR

UPDATE ZDUBFRREQUESTH

SET STATUS = V_NEW_STATUS

APPROVED_DATE = V_APPROVED_DATE

APPROVED_TIME = V_APPROVED_TIME

WHERE REQUESTNR EQ REQUESTNR.

Please note that these programs have been running perfectly for last 4years and offlate this is happening (last 3months) and this occurance is not regular but happens on random days with only few records in whole lot.

I was wondering what could have been wrong wtih the same program to behave suddenly like this? One point though, our system has undergone Kernal upgrade and to we observed this pattern more after that... Hence I will be posting this in BASIS forum also.

Any kind of help in giving various possible reasons will be highly appreciated.

Thanks a lot,

Rgds,

Lakshmi

[Former Member]

Hi,

I dont have idea about why it is failling oftenly, but I think when it is failling to update/modify can you check whether any run time error is triggered in ST22.

I think the statement is failling in updating some of the field due to some inconsistancy may be in data base then surely it will gives you short dump at that time.

Kindly update this to forum...

Thanks,

Anmol.

[Former Member]

Dear Anmol,

Thanks for the quick response but as I mentioned this program is running successfully for last 4years with no changes to the coding.

Also there are no RUNTIME ERRORS/UPDATE TERMINATION ERRORS observed for these failed transactions. We are using SY-SUBRC check in-order to identify the issue but I am trying to identify the possible root cause for the same.

Rgds,

Lakshmi

[nirajgadre]

Hi,

Try to check the update llog for your program in transaction SM13. it might give you the idea why update/modify statement is falling for perticular records. Also i think the update or modify statement will failed due to the type of present in those records. try to check the is there is any data issue related to those entries.

[Former Member]

Hi Lakshmi,

Are these table being updated by anyother transaction also?

Could this be a data locking issue?

You can try using enqueue and dequeue before updating and modifying.

[Former Member]

Hi ,

how abt the COMMIT WORK , where you are calling it ?

regards

Prabhu

[Former Member]

Hi All,

Thank you all for guiding me through verious aspects unfortunately all these have been explored with no +ve results.

@NIRAJ: To my knowledge SM13 is for monitor for UPDATE TASKS and general MODIFY/UPDATE statement on a ztable in direct program may not be captured (I checked but could not find any records). Please correct me if my understanding is wrong.

@SAP_WIZ: This table has not being updated by any other trasnaction but only this program. So no chance of RECORD LOCKING.

@PRABHU: We are checking SY-SUBRC and if it is EQ 0 then I am performing Commit work. But SY-SUBRC itself is not returning 0.

Inputs in any other aspects to be considered will highly be appreciated.

Thank you all,

Rgds,

Lakshmi

[Former Member]

hi,

i would suggest, you should identify the entries for which these statments are failing.

The update statementhas a where clause, its possible teh key fields donot match.

Modify statement should ideally create an entry if data doesnt exist in table, but just try finding out is this happening for some specific entries.

[Former Member]

Hi,

We faced a similar error with modify, we have used Transporting addition and it worked.

Try using Addition Transporting field1 field2 ..etc in the modify statement.

Thanks,

Venki.

[Former Member]

Hi,

While problem concern UPDATE statement there could be circumstances that sy-subrc will be NE 0 - it's normal.

F.e. Update rows which not exist.

In my opinion problem is while sy-subrc NE 0 after MODIFY statement. MODIFY (UPDATE/INSERT in fact) should always returns 0, even with empty work areas.

Furthermore when sy-subrc NE 0 there is nothing for commiting.

Daniel.

[Former Member]

Hi,

Answering your suggestions/questions on my issue below and hope to have some more views which can point me to right direction.

SAP_WIZ: I have posted this only after careful analysis and the where clause as mentioned in my original post (Question) has one field that is primary key. So the question of conflict in where clause is ruled out.

DANIEL: As I mentioned in my original post WE HAVE UPGRADED OUR KERNAL recently and only after that we have been reported these issues. So can this be a reason??

I actually posted this same question in BASIS forum also having to get answer from KERNAL UPGRADE PERSPECTIVE but it seems posting same tread in multiple forums is agianst the rules and it has been locked there so could not really get any answer

So if Any of you with all your rich experiences of working with various clients can guide me in that direction also it will be helpful.

Thanks a lot to all of you for ur valuable time spent.

Rgds,

Lakshmi

[Former Member]

Hi,

you wrote that table update is only done by your program. But are you sure that program is only running once and can't be called a second time while it is running?

If it runs in batch maybe a job has to wait for a free batch process and a later job for this program will bes started without wait, so they can have overlapping runtime!

Do you call a commit after each MODIFY or only at the end? System can manage only a limited number of table updates (for all runing programs at the same time).

Regards,

Klaus

[Former Member]

Halo lakshmi,

What I would suggest is to write log entries if sy-subrc for the modify / update statements is ne 0.

You can use the FM BAL_LOG_CREATE for the same . You can see the created log in transaction SLG1 .

You can see program SBAL_DEMO_01.

Regards

Arshad