The information contained in the SAP systems, and thus in the database, can be classified in two

groups:

Data that are client independent, and therefore valid for all clients

Data that are client dependent, and only available in the specific client

The client-dependent data are treated by the SAP system in their own special form. When a user
is logged on in a SAP session in a particular client, the user is only able to see data that belong to
that client or data that are client independent. The way SAP internally implements this is by
having the client field as a key field in the records that belong to tables that are client
dependent. An easy way to test this is by accessing directly with the database tools and doing an
SQL select statement in one of those tables. There are a few thousand tables that are client
dependent. These tables always include the client field (known as MANDT although the name
can be different) as part of the primary key. This field always has table T000 (the clients table) as
a check table.

Internally, the underlying SAP database system, like in the preceding example, does not know
about the limits imposed by the client within the SAP system. However, the ABAP Open SQL
statements normally only know about the client in which the users are logged on. The client
concept allows for having several work environments within the same SID. These work
environments are treated as different business entities, although they are often used for testing,
demo, training, different customizing modules, and so on, which makes it very normal to find
several clients under the same SAP system. The SAP system, as was introduced in previous
chapters, includes three standard clients from the standard installation: clients 000, 001, and
066. In new installations, there are two standard clients 000 and 066.

Client 000 is the reference client with a complete society model and with sample data. SAP
recommends not working in this client for productive purposes, except for those administrative
tasks that are performed in client 000.Client 001 is a copy of client 000, which customers can use
to start the customizing work or use also as a reference client. Client 066 is a special client used
by the SAP service personnel to perform the preventive maintenance service, EarlyWatch. Apart
from the standard SAP clients, customers can create their own, as many as they consider
necessary.
Pay attention, however, to the storage needed for having too many clients. The SAP system
includes functions for creating, copying, and deleting clients, as well as the necessary options to
access the client data without altering the consistency or integrity of the database. It's important
to use the SAP-provided functions for managing clients and not to perform them with database
utilities because there is a high risk of creating inconsistencies in the system. Right after
installation, to start working with the SAP system, one of the first post installation steps is to
create a new client. When the client is initially created it contains no data.

From this newly empty client, administrators have to decide whether to fully copy another client
into it or copy just parts. Initially, your reference clients for copying are the SAP standards. Then
when your installation has more clients, the source client for the copy can be any of the existing
ones in the system. The next section explains the functions that SAP makes available for doing
client copy management functions.

Client Copy Tools

The system includes five tools to perform client copy functions. All these tools are available from
the Tools | Administration | Administration | Client Administration menu. Figure contains the
menu tree client administration. Options under this menu are as follows:

Client Maintenance, transaction SCC4. It's the function for maintaining system clients: creating
new ones, modifying attributes, and so on.

Client Copy. It's the main client copy function and includes two options:

Local Client Copy, transaction SCCL. It's the function for copying clients within the same SAP
system.

Remote Client Copy, transaction SCC9. It's the function for copying clients among different but
connected SAP systems.

Special functions. Includes special functions for client maintenance such as deleting clients,
comparing tables between clients, or copying a client in base to transport request. Menu options
are as follows:

Copy Transport Requests, transaction SCC1. Used for "internal" transports.

Delete Client, transaction SCC5.

Client Transport. It's the function for performing client copy transport functions and includes two
options:

Client Export, transaction SCC8.

Import Editing, transaction SCC7.

Copy Logs, transaction SCC3

Copy Logs, transaction SCC3. This option presents the list of the client copy logs and allows copy
progress to be monitored.

Customizing objects:

Cross System Viewer, transaction SCU0.

Object Comparison, transaction SCMP.

Client administration options

Client administration options

The main options for client copy and maintenance are explained in the following sections.

Creating a New Client

To create a new client for being the target of a client copy, you first have to define that client.
The client definition is performed by selecting Administration | Client Administration | Client
Maintenance from the initial administration menu or, alternatively, by entering SCC4 transaction
code in the command field. The system displays the client table, T000. In this table you can
define additional clients or modify the information of the already-defined clients. If the table is
in display-only mode, click on the Display/Change icon to set the table to maintenance mode.
The system displays a message warning that you are going to update a table that is client
independent and will show the Client table overview.

Client table T000

Client table T000

To create a new client, click on the New Entries button. You get a screen like the one.

Defining a new system client

Defining a new system client

On that screen, you must enter the client number in the corresponding required input field.
Enter a descriptive text and other optional information in the available fields. When your input is
complete, click on the Save button to save the new entry.

Changes and Transports for Client-Specific Objects

When creating new clients, there are four options to consider for client-dependent objects
according to the possibility of changing client customization and possible transport to another
clients or systems. These options are as follows:

Changes without automatic recording. When setting this option the client can be customized,
although the system will not automatically generate change requests. If users later wish to
transport customizations performed on this client, the transport requests must be manually
created. This flag is not usually set except for test or demo clients and is not suitable for
development and customization.

Automatic recording of changes. With this option, customizing is allowed on the client, and all
changes are included on change requests that can later be transported to other clients or
systems. This is the usual configuration for developing and customizing clients on development
systems.

No changes allowed. This option does not allow any modifications to be performed on the client.
In this case the client is protected (locked). This is a usual configuration for productive clients
where customization should not be performed. It is possible, however, to export the
customization settings of this type of client using manual generation of a transport request.
Changes without automatic recording, no transports allowed. Changes are allowed with this
option; however, customization settings cannot be transported either automatically or manually.

Cross-Client Object Changes

This setting establishes which clients are authorized to perform maintenance of

clientindependent data. The fact that cross-client or client-independent data exists and is
common to all existing clients means that a change in any of this data affects all system clients.
Cross-client data include all repository objects (programs, table definitions, screens, and so on)
as well as some common types of client customizing.

Four possible options for this setting are as follows:

Changes to repository and cross-client customizing allowed. With this option there are no
restrictions on this client for changes and development.

No changes to cross-client Customizing objects. This option allows for development on

repository objects but not on client-independent customizing.

No changes to Repository objects. This option lets users perform clientindependent customizing
but no development or modifications to repository objects.

No changes to Repository and cross-client Customizing objects. This setting prohibits any client-
independent modifications and is common on productive systems.

Protection: Client Copier and Comparison Tool

This option is a security measure used for avoiding undesired client copies or client overwriting
and for prohibiting access for the purpose of comparing customization settings with those of
other external clients. The three options are as follows:

Protection level 0: No restriction. There are no restrictions, so a copy could be duplicated or

compared.

Protection level 1: No overwriting. Client cannot be overwritten by a client copy.

This should be the standard setting for productive clients.

Protection level 2: No overwriting, no external availability. Client is protected against read access
by other clients—for example, comparing the customization settings using client comparison
tools.

Restrictions

Client definition can additionally include several special restrictions:

Restriction when starting CATT and eCATT. Within this box, you can decide among several
options to allow or deny access to this client in order to be used as a test client for the SAP
Computer Aided Test Tool (CATT) and the eCATT tool.

Currently locked due to client copy. The system sets this flag automatically when a client copy is
in process, thus disabling work on this client temporarily until the client copy is complete. When
the copy is finished, the program releases the lock and unsets this flag.

Protection against SAP upgrade. This flag can be used for preventing a SAP upgrade from
overwriting customization settings on this client. This is a very special option that should be
carefully used in accordance with SAP upgrade instructions and particular installations.

Requirements for Creating Clients and for the Copy Process

When creating new clients there are some requirements that must be considered. One of the
main factors is the storage requirement. Creating a new client is like creating a new structure
inside the database. So, before actually creating and copying the client, you should ensure there
is enough space for it. This can be done by executing a client copy in test mode, which outputs
the database space requirements for the new client in the copy log. SAP recommends at least
500 MB of free space for a client with no application data.

Other restrictions that apply during a client copy process are as follows:

No users should be working on either the source or target clients, because this might cause
inconsistencies. Administrators should lock users on the source client for entering the system.
Only SAP* and DDIC are allowed to log on to the system.
The client copy should run in background and if possible at night. In this case, ensure that no
background process is scheduled to run in the source client that could modify the database at
the time the client copy process is running because it can cause inconsistencies in the database
just as normal logged-on users would.

In order to launch a client copy, the following authorizations are needed:

S_TABU_CLI allows the table maintenance in all system clients.

S_TABU_DIS permits the content of the CCCFLOW table to be modified.

S_CLIENT_IMP permits data import when doing a client copy.

S_DATASET_ALL allows log files to be written in the file system.

S_USER_PRO permits copying user profiles.

S_USER_GRP permits the user master records to be copied.

When users need to create and export object lists for a client export, the following authorization
also might be required:

S_CTS_ADMI is the authorization for performing administrative functions on the transport

system.

S_TABU_RFC is the authorization allowing access to tables in a remote system, and required for a
remote copy.

As the system superuser, SAP* has all the needed privileges to launch a client copy. SAP
recommends performing the operation with SAP* or with a self-defined superuser having all the
system access privileges. Be careful when copying a source client over an existing client, because
the process will first delete all the tables' contents in the target client before importing the new
data from the source client. If the source client includes very large tables, it can result in long
runtimes and also there is the risk of rollback segments overflow. When possible, enlarge
rollback segments before performing a client copy.

When copying clients between different SAP systems, copy only the client-dependent tables.
Copying cross-client (client-independent) tables can only be performed when the target system
has not been customized yet; otherwise, the copy process will overwrite the existing tables and
this might leave the target client in an inconsistent state. Depending on how—what is copied—
the client copy is performed, you must watch out for the system number ranges. SAP
distinguishes three different situations:
When customizing and application data are copied, the number ranges are copied together with
data because application data refer to number ranges.

When only customizing data are copied and application data are deleted, the number ranges are
reset.

When only customizing data are copied but the application data are not deleted, the number
ranges and application data are retained.

According to the table and table class selection, these are selected based on delivery class. This
setting determines whether the entire table or only part of it (the clientdependent part) is
copied. You can see it on transaction SE11, then select the table name and Delivery and
Maintenance tag. The Delivery class field shows this table attribute. All customizing tables will be
copied except those with the following delivery classes

L. These tables should be empty on the target system.

A. Application tables.

W. System tables, which are internally filled.

Copying a Client in the Same System

Copying a client requires the following steps that we will explain further in detail. You should
check and restrain users from actually logging into the system:

Defining the new client

Logging into the new client with user SAP* and password PASS

Selecting a copy profile and a source client and launching the client copy

Checking the copy log

When you have defined a new client as indicated in the previous section, you can automatically
log on to the new client with user ID SAP* and password PASS. Once logged on in the target
client, from the main menu, select Tools | Administration | Administration | Client
Administration | Client Copy | Local Copy or, alternatively, enter transaction code SCCL in the
command field.
In the Selected Profile input field, you have to enter a profile that tells the function what to copy.
The SAP system includes a group of predefined profiles. Click on the possible entries list arrow to
display a list of the available copy profiles.

Entries list for copy profiles

Entries list for copy profiles

If you want to copy the whole client, including users, customizing, master, and transaction data,
select the SAP_ALL profile.If the profile selected includes user master data, enter the source
client for the user master in the Source Client User Masters field. In the Source Client input field,
enter the source client for the copy. It is advisable to perform a test run before the real execution
of the copy. The test run informs you about storage requirements and possible problems when
copying clients. Finally, you have to execute the copy. Depending on the chosen copy profile,
these functions can take a considerable amount of time. Therefore, it is recommended to
execute the client copy functions in the background. You should only execute them online when
copying users' master data only.

Deleting Clients

There are several possibilities in the SAP Web Application Sever systems for deleting a whole
client. The first one is by using the standard Client Delete transaction, SCC5. Log on in the client
to be deleted and make sure no users are logged on to this client. Then, from the main menu,
select Tools | Administration | Administration | Client Administration | Special functions |
Delete Client or enter transaction code SCC5 in the command field. This function also gives you
the possibility of specifying whether you also want to delete the entry from the client table
T000. You can execute this function online or launch it in the background. You can check the
client deletion process by looking at the log with transaction SCC3.

Deleting a Client with R3trans

Clients can also be deleted using the R3trans programs, which can be the fastest way. For
example, suppose that the SAP system name is TT1 and the client to delete is 010. To delete this
client, log on at the operating system level as user tt1adm and access the /usr/sap/trans/bin
directory (i.e., cd/usr/sap/trans/bin). Using a standard editor, create a control file, for example,
delcli.ctl, with the following text:

clientremove

client=010

select *

where 010 is the client number to be deleted. Save the file and execute the command:

R3trans -w delcli.log -u 1 delcli.ctl

Status after Deletion

After deleting a client, the space is not automatically freed from the database, although these
free areas can be filled up with new data. When a client has been deleted and a new client is
created and then copied, the space that was freed can be reused by the new client. To restore
the free space immediately after a client delete, you should perform a database reorganization.
This is only recommended in cases where the deleted client had a lot of data and you don't
expect to reuse that space. And also in case, for performance reasons, you want to fill up the
gaps left for the deleted data.

Client Copy Logs

Any of the client copy functions generate a log file that can be displayed by using transaction
SCC3. From the administration initial menu, select Administration | Client Administration | Copy
Logs. The system displays a list with the target clients for the copies, number of runs, and date of
last run, and a short status text. From the initial screen you can select the copy log you want to
display and navigate to see the full details of a copy process. To do this, double-click on the
needed client line. The system displays the list of logs. Select one to display the client copy log
analysis. Then to display the details or the full file copy log, select Choose from the application
toolbar. In the next screen, you can select the Details or the File Log.
Restarting a Client Copy Process

If for any reason (such as database storage problems) the copying process has been canceled,
when trying to reexecute the same copy process, the system allows you to restart the copy at
the point where it was previously terminated, using the same parameters as before. The client
copy programs use the client copy control flow table, CCCFLOW, which includes checkpoints.
When you are presented with the option of restarting the copy process but you don't want to
use the restart option, select the NEWSTART option.

Transporting Clients between Two SAP Systems

This process can be useful in cases where there is no direct network connection between two
systems; otherwise, a remote copy is preferable. For example, suppose you want to copy client
005 from a source system TT1 to target system DD1 The target client can be 005 or any other
client. If the client does not exist in the target system, DD1, first log on to the target system in
any existing client and create the new client by using the standard function, for example, Tools |
Administration | Administration | Client Administration | Client Maintenance. If the client
already exists in the target system, you should first delete it. Refer to the previous section on
deleting clients.

Log on in the source system in the client you want to copy (to export). In this example, system
TT1 and client 005. Enter transaction SCC8 in the command field or, alternatively, select
Administration | Client Administration | Client Transport | Client Export from the initial
administration menu. Enter the same copy profile as you would in a normal copy procedure
between clients in the same system. You must select what you wish to transport by using one of
the existing copy profiles, as shown in Figure 9-10. Copy profile management is explained in the
next section. Execute the copy in the background.

When the export is finished, and depending on the chosen copy profile, you get the following
transport requests:

TT1KOnnnnnn (cross-client objects)

TT1KXnnnnnn (client-dependent long texts)

TT1KTnnnnnn (client-dependent tables)

where TT1 is the SID and <nnnnnn> is a system-generated transport number. Now you have to
import those transport files manually using the Transport Management system in the target
system. After importing the KO and KT, you have to run transaction SCC7 in the target system for
the import postprocessing, in which text files are automatically imported. Check the transport
log for errors. Because client transports and export/import options vary between different
releases of the Basis system and the WAS, please refer to the latest version of SAP Note 70547
for updated information and known problems.

Copying Individual Tables Entries between Clients

In addition to the previous functions and transactions used when performing client copy
functions and the associated reports, SAP provides additional reports that can be very useful
when managing information among system clients. You can use transaction SCC1, which allows
you to "transport" an object list from a source client to the current logon client. Watch out with
certain restrictions for long tables, and refer to SAP Note 45796.

Other possibilities for copying individual table entries between clients include, for example,
programming in ABAP the transfer of the data to a file and then loading that file on to the target
client. And finally, you could transport the table contents by creating a transportable change
request and entering the table contents in the transport editor. For table contents, use the R3TR
TABU <table name> option. However, you should avoid using these last two options, which can
cause inconsistencies in the system data.

Copying Tables Entries between Two Different Systems

There are several ways to copy table entries between two different SAP systems. One of the
most efficient is by using the R3trans utility. The tp program could also be used; however, the
transport control program tp performs many additional checks and imposes some restrictions on
the table types to be transported. For example, assume that, after a client copy between two
SAP systems, a table content could not be completely copied to the target system (import phase)
because the table reached the maximum number of extents in the underlying database. You can
avoid having to perform a whole import again by transporting a single table with R3trans. The
general procedure to do this is as follows:

Create the control file for the export.

Run the control file in the source system.

Check the export log.

Create the import control file in the target system.

Run the import control file in the target system.

Check the import log and the data in the target system.

Example of Copying Table Entries between Clients and Systems

The following example shows the copying process of the contents of a table from the client 002
in system C12 to client 010 in system T12. After verifying the client copy log, due to some storage
problems in table MOFF, this table could not be completely copied. To avoid having to perform
the whole client copy process, just the entries on table MOFF from the source client will be
copied to the table MOFF on the target client 010 in the target system T12.

In the source system (C12), create a control file, for example, expmoff.ctrl with the following
content:

export

client=002

select * from moff where mandt = '002'

Run the R3trans utility with the previous control file:

R3trans -w expmoff.log –u 18 expmoff.ctrl.

The R3trans syntax and options are discussed in Chapter. While the -w flag indicates the log file,
the -u flag sets unconditional modes for the transport. In the export phase, unconditional mode
1 indicates the system to ignore the wrong status of transport requests. Mode 8 allows direct
selection of tables when the default modes are not allowed.

By default, the previous command generates the data file trans.dat in the directory where the
export has been executed. If both source and target systems share the transport directory, it
won't be necessary to copy the trans.dat file. Otherwise, you must use available tools for file
transfer, for example, ftp.

Check the export log file, expmoff.log, and verify it did not contain any errors.

Once in the target system, create the import control file, for example, impmoff.ctrl, with the
following content:

import

client=010

Then execute it with the R3trans tool: R3trans -w impmoff.log -u 248 impmoff.ctrl. By default it
uses the data file trans.dat generated by the previous command file.

The unconditional modes used in the import phase are 2 for enabling the overwriting of the
original; 4, which ignores that the transport request was intended for a different target system;
and 8, which allows for importing tables that are restricted by their table types.

If you use the default options for the import, you do not need a control file. The import can be
performed directly with R3trans -i <file>.

Check the import log file, impmoff.log, to check that the import runs fine without errors. You can
also log on to the target client, 010, in the target system and look up the table contents with
standard dictionary utilities, such as the data browser (transaction code SE16).

« Previo