Comparing two SAP clients

Comparing two SAP clients

Compares Customizing objects in two logical systems with transaction SCU0.
(clients in either the same R/3 System or different ones).

To compare objects, start the Customizing Cross-System Viewer in the logon client 
(client of the system in which you are logged on) and then logon in the compare client 
(client to be compared).

The Customizing Cross-System Viewer compares Customizing objects by the following criteria:

- Project IMG
  This option shows changes in your project.

- Application components
  This option compares Customizing objects in specified application areas.

- Business Configuration Sets
  This option concentrates on Customizing settings which are of particular importance for 
  the processes in your company. 

- Transport requests
  This option shows the objects which would be overwritten by a transport.

- Manual selection
  In this option, you specify which objects are compared.
 

The compare client security level must be:

0 (unrestricted), or 
1 (no overwriting)

You can set this in the client maintenance SCC4.

You must also create a Remote Function Call link in SM59.

SAP Language Error when logging in after Upgrade to 40B

-----Original Message-----
Subject: Language Error when logging in after Upgrade to 40B

Dear all,
we have recently upgraded our system from 3.1H/Oracle 7.3.3/HP-UX
10.20/CIN 2.1A to 4.0B/Oracle 8.0.4/HP-UX 10.20/CIN 2.2A.

Upgrade went fine without any major hassles.
After upgrade when I am logging in it is giving a message in an
information dialogue box "Specified Language has not been installed completely".

How to correct the error ? Everything is fine other than this.

Thanks.

-----Reply Message-----
Subject: Language Error when logging in after Upgrade to 40B

I also got the same error for the same situation. Here is the solution:

The reason for this is that table TCPDB was not maintained in your
system before the upgrade and the upgrade process was unable to import
the special texts as it couldn/t find the correct codepage ( in TCPDB ).
This can be rectified by the following:

Logon to 000 client

1) Run program rscp0004 in transaction se38 and this will give u
options to insert a codepage. Look for codepage 1100 in the list and
press F2 on this line as suggested, to insert the codepage.

2) In transaction SMLT check the 'status' of the installed languages.
You will probably find that its the 'special texts' that were not
imported successfully ( because the codepage could not be found in TCPDB
at the time of the upgrade )

3) Schedule a 'full' import of the 'special texts' for the languages
that are affected. Plsease note that when scheduling these imports, the
options for Customizing and Documentation are automatically ticked for
selection. Please remove these to leave only the Special Text selected.

You can observe the progress of the imports with sm37. After successful
completion, you can logon again and there should no longer be an error.

-----End of Message-----

Information on how the OPS$ Users Work

Does anyone have information or a good understanding of how the OPS$ users work and operate under an Oracle SAP environment.

I would greatly appreciate some assistance as I have problems with my Brconnect and Brbackup within DB13 due to the OPS$ users.

I need info on how to permanently delete the OPS$ users and then recreate it, due to the fact that I have incorrect OPS$ users in some of the tables affected by the OPS$ users.

Below is the document I have prepared on recreating the OPS$ machanism. It helped me solve all my problem on DB13 and also on Schema owner connecting to database.

Hope this could help you.

Also refer to the following sapnotes: 
1. 400241 : Problem withe ops$ or sapr3 connect to oracle
2. 134592  : Importing the SAPDBA role (sapdba_role.sql)
3. 361641  : Creating OPS$ users on UNIX
4. 50088   : Creating OPS$ users on Windows NT/Oracle
5. 437648  : DB13: External program terminated with exit code 1/2

----------

select owner from dba_tables where table_name='SAPUSER';

## If owner is not the sid you require, then drop the table SAPUSER

Drop table "<owner>".SAPUSER;
#or#
Drop table "domain\OPS$SIDadm".SAPUSER;

## IF THE ANSWER IS 0 ROWS SELECTED THEN CREATE THE TABLE SAPUSER

# Check whether OPS$<SID>adm user exist, if no then create it

create user OPS$SIDadm default tablespace psapuser1d temporary tablespace psaptemp identified 

externally;

# if exist then drop it;

DROP USER OPS$SIDADM;
 

# Grant connect & resource roll to OPS$<SID>ADM;

grant connect, resource to OPS$SIDADM;

# Creat table SAPUSER

create table "OPS$SIDADM".SAPUSER ( USERID VARCHAR2(256), PASSWD VARCHAR2 (256));

# update "OPS$<SID>ADM.SAPUSER with the follwoing command

insert into "OPS$SIDADM".SAPUSER  values ('SAPR3', 'sap'); #sap = <password>

# Under NT it is required that user sapservice<sid> can also access the SAPUSER table. In order 

to avoid problems with the data consistency, it does not make sense to create an additional 

SAPUSER table having the same contents. You should rather define a synonym. Check if a suitable 

synonym exists by using the following call:

SELECT OWNER, TABLE_OWNER, TABLE_NAME FROM DBA_SYNONYMS WHERE SYNONYM_NAME = 'SAPUSER';

# IF NOT THEN CREAT IT 

create public synonym sapuser for OPS$SIDADM.SAPSUER;

# if synonym already exists drop the existing synonym by the following command

drop public synonym sapuser;

#If another name <name> is returned as first value:

DROP SYNONYM "<name>".SAPUSER;

# AND CREAT it again with above command

# To allow access to the synonym (or the associated table), a grant
            needs to be executed. The authorization for this has only the
            ops$ user who is the owner of the actual table - that is
            ops$<sid>adm. Therefore, you need to log on with the
            corresponding operating system user (<sid>adm) and execute the
            following commands:

            CONNECT /
            GRANT SELECT, UPDATE ON SAPUSER TO "OPS$SAPSERVICE<sid>";

# Now you can recreate the synonym (not PUBLIC, if possible):

 CREATE SYNONYM "OPS$SAPSERVICESID".SAPUSER FOR "OPS$SIDADM".SAPUSER;

 CREATE SYNONYM OPS$SAPSERVICESID.SAPUSER for OPS$SIDADM.SAPUSER;
 

# COMMIT AFTER COMPLETION of the activity & restart the DB