cancel
Showing results for 
Search instead for 
Did you mean: 

version upgrade error JOB_RSVBCHCK_R

Former Member
0 Kudos

Dear experts,

As part of our test upgrade from SAP 46C to ECC 6.0 we faced an error in

phase JOB_RSVBCHCK2, where upgrade phase list ToC suggests to check

t-codes SMQ1,SM13 and we couldt find any outstanding update tasks, so we

continued by ignoring the phase. Now one more error occured in

JOB_RSVBCHCK_R phase,again we check the SMQ1,SM13 T-codes,didt find any

outstanding update tasks. so when we try to ignore the task it is

asking for password provided by SAP to ignore the phase.

is it recommended to skip this phase?if yes does anyone have password to skip the phase?

regards

raghu

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

There are obviously unprocessed items in the queue. You must clear the queue before proceding, or manually delete entries in the affected tables in the queue entries are of no relevance to you, such as in a IDES system.

Alternativly you can request a password only from SAP

Former Member
0 Kudos

hi deijkers,

i contacted SAP regarding this and they recommended to clear the the queue using SM13 and SMQ1. if nothing visible in these T-codes , they recommend to clear update related tables using SAPGUI or if not able to delete from SAPGUI, entries in the above tables should be deleted from database level ...

thanks a lot for your comments..

regards

raghu

Former Member
0 Kudos

Dear L Raghunahth,

I am doing technical upgrade testing on my copy of R/3 production. ( from R/3 Enterprise to ECC6.0 SR2) and I am facing the same problem.

I cleaned up all update record from SM13, SMQ1, SM37, and STMS, but the problem still remains.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CHECK OF UPDATE TASK Errors and RETURN CODE in RSVBCHCK.TQ1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2EETG050 Update records still exist - Please process

You said that you had to clean up update related tables from DB level. Can you tell me which tables are related to updates?

Thank you.

Former Member
0 Kudos

I found it myself.

they are VBDATA, VBMOD.

Delete all entries from these two tables from SQL, then it went thru.

Thank you.

Answers (1)

Answers (1)

Former Member
0 Kudos

I know this was answered, but just wanted to post this for the greater good, in case someone else gets stuck as we did...

During Prepare, we got this error

CHECK OF UPDATE TASK Errors and RETURN CODE in RSVBCHCK.EQ0

A2EEMCEX 151 Entries for application "11" still exist in the extraction queue

Long text:

Cause

Changing extraction structure &V#& for application &V#& is forbidden,

because there are entries that have not yet been processed into an

extraction queue for application &V#& for at least one client.

If an extraction structure is changed to the entries that are still

open in an extraction queue, then these are no longer able to be read

and can cause terminations with the collective update.

What to do

Start the collective update using the function "Job Control" in the

<DS:TRAN.LBWE>Logistics Extraction Structures Customizing Cockpit</>.

To get an overview of the logistics extraction queues, see the

<DS:TRAN.LBWQ>Logistics Queue Overview</>.

During Prepare we clicked Ignore because we checked all the active clients on this QA box and nothing for those existing clients was in SMQ1 (or SM13 for that matter). And in LBWE we had turned all the extractors to Inactive (because our BW system has been not operational for years, and we did not really need extractors RFCs running).

Prepare ended with this error in the checks.log but we thought we could proceed with the SAPUp.

Then during the actual upgrade, we get the same error, only it won't let you past it without fixing it or getting a password from SAP. One problem is - you can only login to client 000 at this point. The other problem was that the Upgrade was checking these RFCs in a non-existent client!

As prerequisite, we know that we have to go to SMQ1 (same as LBWQ) and delete any outbound RFC queues. The problem in our QA box was that there were some from an old client 444 which did not exist. So we can see these old RFCs pending from SMQ1 because it shows the client. But SMQ1 doesn't let you delete entries from other clients.

SAP has a ABAP RSTRFCQD which (per note 763255) deletes queue easily in background. But this ABAP can't delete in other clients other than the client in which its executed.

We tried recreating the client just so we could login and run this ABAP, but we did not have the SAP* password for that old client.

We felt it was easier to just manually delete the entries rather than deleting SAP* and restarting the system.

So we just used SQL and deleted the entries from client 444 in the same table SAP's job RSVBCHCK was checking:

delete from TRFCQOUT where QNAME = 'MCEX11' and MANDT = '444'

delete from TRFCQOUT where QNAME = 'MCEX12' and MANDT = '444'

Restarting the upgrade gets back the check in the phase of RSVBCHCK.

In Production, we don't have extraneous clients, so this should not be a problem.