Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Error in updating custom database table using UPDATE SET Command

Former Member
0 Likes
1,222

Hi,

I developed an automated collection system program in one of our clients simulating FBE1 (Payment Advice Creation) and F-28 (Posting of Incoming Payments) transaction codes. Upon posting, we encountered an error in PRD server wherein, for some of the posted items, the STATUS field in our custom table was not successfully updated. We tried to reverse the clearing document and debug the program. Upon posting, we were able to successfully update the status. We could not simulate the error in QAS since all the postings in QAS were successful and all status' relating to these postings were updated as well. We tried posting multiple times and the program seems to be working fine. In PRD, this behavior is just random and there is no specific pattern as to how the error occured. Provided below is the code I used for updating custom table ZFIACSF28. The STATUS field should be equal to '4' once the posting is successful. We are not sure if this is a database related issue. 7 users are authorized to do the postings in PRD and they are using the same user account.

CODE:

CALL TRANSACTION 'F-28' USING gt_bdcdata

MODE 'E'

UPDATE 'S'

MESSAGES INTO gt_messtab.

READ TABLE gt_messtab INTO wa_messtab WITH KEY msgtyp = 'S'

msgnr = '312'.

IF sy-subrc EQ 0.

        • update status for items cleared bearing the same OR Number*

UPDATE zfiacsf28 SET status = '4'

zsapdocument = wa_messtab-msgv1(10)

zruntime = sy-uzeit

zrundate = sy-datum

WHERE zor = gv_zor

AND customer = gv_customer.

COMMIT WORK.

ENDIF.

7 REPLIES 7
Read only

Former Member
0 Likes
1,048

Hi,

the issue may be caused by calling the transaction by mode 'E' .

Please check, if there is also an issue calling the transaction in mode 'N' .

Some messages may be lost, if the transcaction enters the error mode in dialogue.

What about the fields ZRUNTIME and ZRUNDATE ? Are they updated, or is update failing on these fields, too?

Regards,

Klaus

Read only

0 Likes
1,048

Hi,

If I will be using MODE 'N', the program or the transaction would not stop at the point where the error occurred. Normally, when an error is encountered, the manual clearing screen of F-28 would show up.The behavior is very random. There were times wherein the STATUS field is updated, while ZSAPDOCUMENT (Clearing Document Field) is not updated. There we also times that only the ZRUNDATE and ZRUNTIME fields were updated. I also tried reversing the same document the user has posted and tried posting it again. Upon doing this, the STATUS was updated. I also have a internal table where i store the clearing documents generated upon posting and display these document numbers when the user press the BACK button.

Read only

0 Likes
1,048

Please use wait for 1 or 2 seconds after commit. seconldy please provide the key fields of custom table zfiacsf28

Nabheet

Read only

Former Member
0 Likes
1,048

Hi,

it's not possible that status isn't updated in zfiacsf28 while date and time are updated there, because it's hard coded.

There must be other programs that also change your table zfiacsf28 and maybe clear those fields. Maybe the key fields zor and customer cannot provide duplicate access, what is the meaning of field zor ?

Please check the where used list of table zfiacsf28 to find other update programs.

Regards,

Klaus

Read only

0 Likes
1,048

hi,

can you please check the key fields of the table?

it may be possible that the key fields are not allowing to update the data due to data inconsistency problem.

Read only

Former Member
0 Likes
1,048

You may be getting deadlocks at the database level. If multiple users can concurrently update the table, you should be locking the table rows you will be updating.

Rob

Read only

0 Likes
1,048

Experience speaks ... Didn't even think about this possibility. But Rob you see that the other fields are getting updated , its not that the whole row is not updated

@OP - are there only two key fields for this table ?

Kesav