EHPI Error: Phase XPRAS_UPG, DDIC_TYPE_INCONSISTENCY...

This is a fairly common error in the EHPI process. Sometimes a table will have an include field that references an invalid field from another table. That field may have one day existed and for some reason no longer does.  In order to move past this error in the phase XPRAS_UPG, you have to purge the offending field.

First, make sure to correctly identify the field. There will be detailed information about the table/field in the Short Dump in ST22. Make sure you are thorough, because you do not want to alter the wrong table. For example, the most recent one I ran into was the NETPR field in table EK08RZ.  The error in the short dump referenced table DRSEG.  The short dump references a report you can run to identify the problem field, but I won't reference here because I REALLY want you to read the short dump.

Here are the steps to correct the problem:

1. Unlock the Shadow System to allow a user to login:

 From the command line, run:
\usr\sap\<SID>\<inst>\exe\TP UNLOCKSYS <SID> PF=<profile path>

2. Set the system to allow for changes:

SE06 -> System Change Options, set the system to modifiable for both Software Components and Namespaces

SCC4, Allow changes to both client dependent and repository objects

3. Remove the field

SE11, modify the table and remove the invalid field

4. Close the system in SCC4 and set the system to Not Modifiable in SE06

5. Lock the Shadow System:
\usr\sap\<SID>\<inst>\exe\TP LOCKSYS <SID> PF=<profile path>

Resume the step in EHPI.

You may run into multiple invalid fields, so be patient with this process.

Hope this helps...

EHPI fails at phase MAIN_SHDRUN/RUN_RADTBUCACT...

During the phase MAIN_SHDRUN/RUN_RADTBUCACT the process fails.  Inside the shadow instance, if you run the program RADTBUCACT manually, you will get the SQL error cannot find stored procedure 'sap_get_object_type'

If you look inside the database, you will see that the stored procedure is there under the <sid> schema, not the sid_shd schema. If you try to run MSSPROCS, you may run into problems as well, since the shadow instance is a remote connection.


To resolve this, you need to create the stored procedure manually.
The easiest way for non-DBA types is to browse to the stored procedures in your database using SQL Management Studio. Right-click on the sap_get_object_type procedure, and choose to script the object as "CREATE" to a query analyzer window. Then change the "CREATE proc" line to reference sid_shd rather than just sid and execute.


The following stored procedures will all have to be available in the sid_shd schema in order for MAIN_SHDRUN/RUN_RADTBUCACT to complete successfully:

• sap_get_index_columns
• sap_get_index_id
• sap_get_index_type
• sap_get_object_type
• sap_get_single_table_of_index
• sap_get_sqltext
• sap_get_table_columns

However, if you do just these stored procedures, you will likely run into the same issue in Phase MAIN_SHDRUN/ACT_UPG, but it will not look as obvious.  The errors you see will have you running in circles trying to setup/fix the transport domain configuration because of RC=12, etc, but the problem really is the fact that there are more missing stored procedures (look at any cancelled batch jobs that were kicked off in your system during this phase, you will see them failing after not finding a stored procedure).  You can either step through this one stored procedure at a time, which will get extremely time-consuming, or you can simply create all of the stored procedures that exist under the sid schema.  The easiest way to do this is as follows:

1. Open up SQL Management Studio
2. Browse to the stored procedures in your SAP database (they are located under "programmability")
3. Highlight all the stored procedures in the sid schema, right-click, and chose to script to QA window
4. Do a find/replace. Replace all [sid]. with [sid_shd]. (do not forget the brackets and period "." or else you will be messing up the scripts.
5. Execute

This will give you some warnings, but it will create all the stored procedures and will get you through this phase of the upgrade.

I hope this helps...

Checks after phase MAIN_SHDRUN/ALTNTAB_FILL were negative!...

Checks after phase MAIN_SHDRUN/ALTNTAB_FILL were negative!Last error code set: BATCH JOB RDDNT2MT FAILED: Error(s) found in the log(s), accumulated in "ALTNTFI.ELG"

In the ALTNTFI.ELG log it contains the following two lines:

"No shadow system""(environment parameter)""auth_shadow_upgrade" "No shadow system""DB-connect not against shadow tables !"

Just in case anyone is running into this error while attempting to upgrade to EHP4 on Windows, here is the solution I came up with:

1. Set the USER Environment Variable ‘auth_shadow_upgrade’ to ‘1’ for the <SID>adm user (set the variable while logged in as that user)
2. Change the Shadow Instance service to run with the <SID>adm account
3. Stop the Shadow Instance (you can leave the Central and SCS Instances running)
4. Start the Shadow Instance
5. Continue the EHPI process from where it left off

The reasoning behind this is that the Shadow Instance must see that environment variable in order for it to connect properly to the database in order to continue with the PreProcessing steps.  There are other ways to force the instance to start with the <SID>adm credentials, but this is the easiest method in my opinion.

Although it would work in many cases, I would not recommend setting a SYSTEM Environment variable, because it will cause trouble if you have multiple SAP instances installed on this server, or if you have to stop/restart the Central or SCS Instances.  You only want the Shadow Instance running with the 'auth_shadow_upgrade' environment variable.

HOWEVER, you MUST remove this environment variable completely prior to the PREPARATION Phase. Otherwise it will cause problems with the upgrade.  This parameter is set and unset during the upgrade process, and leaving it permanently set via the environment variable will not allow it to be "un-set" by the instance profile.

hope this helps...

SAPEHPI "Error when creating cofile for transport request ..."

I just thought I would get on here and share some information about a problem we had while in the Configuration Stage for an upgrade to Enhancement Package 4 for ECC 6.0.
During the PREP_EXTENSION/SUBMOD_EXTENSION_NEW/EHP_INCLUSION phase, SAPEHPI attempts to create data and cofiles for the EHP components. We ran into the following error:

Disassembling patch queue failed rc = 3, reason = 'Error when creating cofile for transport request SAPK-700IHINWEBCUIF

A few of the usual causes for this are:

1. OS Permissions
2. Package corruption (no longer in BIN format, etc)
3. Low disk space in the Transport Directory or EHPI Directory

Typically OS Permissions are the culprit when you run into an error creating the data and/or cofiles for a transport, and that was also the case here. However, you will need to note that there are multiple places to check the permissions.  Not only do you have to make sure that your [SID]ADM user has full rights to the Transport Directory (usually usr/sap/trans on the transport host), but for the purposes of EHPI on Windows, the SYSTEM user must have full rights to the EHPI directory (the directory where you are running the EHPI from).

Apparently on site here, someone had altered the default permissions for the entire drive that EHPI was sitting on, and thus SYSTEM was unable to make changes.

After opening up the security settings for another drive and changing the EHPI drive to match, the process continued on without a hitch.

hope this helps...

Installing RWD uPerform Server on 64bit Win2003...

This comes from Guillermo Gomez, a colleague of mine:

During the process of Configuring the uPerform Server - after installing the Autonomy IDOL/DISH and the RWD Server - at the point of entering Company Name and Product Key, as soon as we click on SAVE we get the error message

Object Required Line 43 - Character 13
webservice,js


Since we are using 64 bit application the ASP.Net file needs to be forced to use 32 bit because RWD sometimes does not recognize the file during the installation process.

1. Ensure the uPerform Website points to use port 80 and the Collaboration Server to use port 8080. This can be verified or change by executing the AuthenticationWizard.exe file located in: <InstallPath>\Collaboration\WWW\uPerformWS\ms
-Click on Start – verify or change the information as needed and ensure the Server DNS Hostname does not have 8080 at the end.

2. Set the permissions to full rights for all users for the file RWD.uPerform.ServerConfiguration.DLL – located in: <InstallPath>\Collaboration\WWW\uPerformWS\

3. Delete the VCBS folders in
<InstallPath>\Collaboration\webapps\

Re-Start IIS

Once is back up:
- Make sure Web Service Extensions is using ASP.NET v2.05727 (32-bit). Remove or prohibit any other ASP.NET.
- Make sure Jakarta Connector is set to allowed if not create a new connector to point to file <InstallPath>\Collaboration\JKConnect\bin\isapi_redirect-1.2.14.dll
- Make sure WebDAV is set to allowed

Inside the websites (iis) right click on uPerform Collaboration and click on properties. Display the tab ISAPI Filters and make sure Jakarta is there and in black font. Any other color (RED) indicates is not connected and you need to delete it from the web services extensions and then add it back in this section … same file location.

Re-Start IIS

Once is back up:
Re-register ASP.NET by executing this file from the command line:
C:\windows\microsoft.net\framework\aspnet_regiis.exe –iru

Once this is done… then do:
C:\windows\microsoft.net\framework\aspnet_regiis.exe –ir

Re-Start IIS

Ensure the website is back up … and continue with the configuration of the RWD uPerform Server.


Hope this helps...

SAP System Message: S...

Recently we were about to begin testing SAPGUI 7.20 on Windows 7 Enterprise for an upcoming roll-out, and we ran into a little trouble.  For some reason we could not get Single Sign-On (SSO) to work correctly. Whenever we tried to log onto the SAP system using SSO, we would get the following error:
"SAP System Message: S"
Not very descriptive, I know.  Apparently this is a fairly common error that will come up for various issues with GUI communication to the system.  When we finally traced the problem to the SAP instance (rather than the GUI itself) we were able to resolve it fairly quickly. The error comes up before being able to access the SAP system, so it is easy to assume the problem lies with the GUI or the network. But our trace showed that everything on the application and network side was working correctly.  SM21 showed multiple "Delete session 001 after error 044" errors. Error 044 is and error in the SNC layer.  So I looked at the instance profile for our system and noticed that the SNC_ENABLE parameter had been set with a value of 0, which disabled SNC for that instance.  All the other instances were still set to 1 based on the values in the Default profile.  Apparently this parameter lingered over from a previous upgrade, and we had just always used log on balancing in that system, so it was never noticed.
After commenting out the SNC_ENABLE parameter (so that the Default profile's values would be used) all of our troubles disappeared.
SAPGUI 7.20 patch 3 works great with Windows 7.

Hope this helps...

Client Copy ends with Error: FINB_TR_CC_EXIT_TARGET...

Okay, so we recently ran a client copy from a productive system to quality. The copy took over 21 hours, and when it was complete, an error was showing.  FINB_TR_CC_EXIT_TARGET was listed under the Table Name field, but obviously that was not a table.  Actually it is a function module, and it was being called at the time of the client copy error.
This ended up being a fairly easy fix.  Since it is apparently common for client copies to fail during the post-processing step, SAP released note 1235955.  If you follow the note it will walk you through completing the process. Worked great for us.

Hope this helps...