In SAP, highest level of organization structure is client. Whenever we login to SAP system, we login to a specific client. Data in the R/3 system is categorized as client-dependent and client-independent. I have collected some details about Client Dependent vs Client Independent concept of SAP.
Client dependent data means the data which user creates in one client is limited to that client only and it is not accessible in other clients
Client Independent means data means the data which user creates in one client that is available in that as well as in other clients
Client Dependent Table
- They have first field called MANDT of type CLNT which contains the client number.
- The data set can be different in this type of table for different client.
Client Independent Table
- They don’t have that MANDT field in table.
- This Table is called cross client table means for all the clients they have the same entries in the table.
Examples:
- Client Dependent: SAPscript and STD texts data
- Client Independent: Smart forms, all dictionary objects data and repository objects data like programs, function modules, tables etc.
Smart Forms are Client Independent because when you activate them you are actually generating a Function Module. This means that the Print Programs actually call a FM instead of using the “OPEN_FORM”, “WRITE_FORM” etc. FM’s that SAPscript use.
There is no specific reason behind why SAPscripts are designed as client dependent and smart forms as client independent!
SAPscript technology is based on a mainframe product from the 1980s. SAPscript forms have always been — under the hood — relatively passive objects, with minimal embedded logic. These forms were designed to be driven and controlled by ABAP programs, much in the way ABAP programs read in database tables to produce reports; if you ever download a SAPscript form (e.g., via utility program RSTXSCRP), and look at the portable text file it produces. Many text objects (e.g., invoice header texts) are bound directly to documents which are client-dependent, so it makes sense for these text objects to also be client-dependent. From a complexity standpoint, SAPscript forms are close enough to these text objects where we can see how it made sense at the time to make them client-dependent too. Sap script was developed a long back and Smart form is developed to avoid these types of some restrictions.
The ABAP editor is client independent. This means that a program, once created, will be available in all the clients of the system. The data that the program tries to access, though, is client dependent.
Understanding Client-Dependent and Client-Independent Tables
There are two types of tables in an R/3 database: client-dependent and client-independent. A table is client-dependent if the first field is of type CLNT. The length will always be 3, and by convention, this field is always named MANDT. If the first field is not of type CLNT, the table is client-independent.
For example: assume there are two clients in system – 800 and 900. A program selects rows from table LFA1 and writes out LFA1-LIFNR. When this program is run in client 800, only those rows are selected where MANDT equals 800. This happens automatically because the first field in the table is of type CLNT. If the user were to log on to client 900 and run the same program, those rows of data would be found and written out where client is 900.
The logon client mechanism divides the rows within a client-dependent table into distinct groups. To access a different set of data, the user logs on and specifies a different client number.
NOTE: The user master records (containing R/3 user IDs) are client-dependent. Therefore, to gain access to a client, the security administrator must create a new user ID for you within that client.
Developers and testers use the logon client mechanism to create and access multiple, independent sets of data within a single table.
For example: assume two typical programmers are working on an enhancement to the billing system. User-1 is modifying the update transaction and is creating a new report to go with User-2′s modifications.
User-2 sets up data for his test run, executes his report and obtains output. User-1 works in the next cubicle, but due to lack of communication he is not aware that his transaction uses the same tables as User-2′s report. He runs his transaction and updates the data. User-1 gets what he wanted, but User-2 then modifies his code and runs his program again. His output differs from the last run, and the differences many not result from his changes, but rather they may result from User-1′s changes. What we have here is a failure to communicate.
If the tables used by User-1 and User-2′s programs were client-dependent, they could each log in to separate clients, set up independent sets of data, and test their programs without ever talking to each other. They could perform all of their testing in the comfort of their cubicles and in isolation from their coworkers.
To make their tables’ client-dependent, they only need MANDT as the first field and the R/3 system will take care of the rest. When records are added to the table, the system automatically moves the current logon client into the MANDT field when the record is send to the database. Their Open SQL select statements will only return rows where the client number in the table is equal to their current logon client number. The Open SQL database statements insert, update, modify, and delete also provide automatic client handling.
If the tables involved are all client-dependent, there can be more than one group of testers working at a time in one test system. Two teams of testers can test divergent functionality in the same set of programs at the same time provided they log on to different logon clients. The updates done by one team will not change the data belonging to the other team.
A training client could also exist on the test system. The students could log on to one client and the testers could log on to another. Both would run the same set of programs, but the programs would access independent sets of data.
NOTE: The average R/3 installation has three systems: development, test, and production. By default, each system comes with three clients installed: 000, 001, and 066. It is common to have from three to six clients in the development and test systems, but rarely will you see more than one client in production.
(Source - Different SDN forum discussions and SAP help)
