database table

[Former Member]

what are the client independent table and

what are the dependent tables?

what is difference between pooled, cluster tables?

[Former Member]

Hi!

A table is client independent, if the first key field of it is not the MANDT field (you can check it in SE11 transaction).

A table is client dependent, if the first key field of it is the MANDT field (you can check it in SE11 transaction).

Regards

Tamá

[Former Member]

client dependent tables - tables which are having client field as primary key field

client indepent tables - not having client field as primary key.

cluster and polled tables chk below link -

http://help.sap.com/saphelp_nw04/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm

[Former Member]

Hi

1) Client dependent table is that table which contains Field name as

MANDT (not compulsory.it can be any thing) but must have type as CLNT (Compulsory).

2) And which does not contain is client independent.

[Former Member]

You can find the answer by searching this forum.

Click 'search forum'

Enter 'difference pooled cluster table' or any such question before actually putting the question for discussion. That saves lot of either sides effort.

Read through the replies.

Regards.

Rahul Dwivedi

[Former Member]

Hi,

Client independent tables dosent have MANDT field.

Client dependent tables have first key field MANDT.

Cluster tables and Pooled tables have many to one relationship with the underlying database.

A table pool corresponds to a table in the database in which all records from the pooled tables assigned to it are stored.

Several logical data records from different cluster tables can be stored together in one physical record in a table cluster.

A pooled table cannot have the name having more than 10 characters.

All the key fields of the pooled table must be of character data type.

In pooled tables, the maximum length of the key field/data fields should not exceed the length of varkey/vardata of the pool respectively.

In cluster table the records having the same key are stored in a single key in the cluster.

If there is an overflow of the data records a continuation record is created with the same table key.

[Former Member]

hi,

tables: which contain MANDT field Means It is a Client Dependent TABLE and IF not It is a Client Indipendent.

Cluster tables and Pooled tables have many to one relationship with the underlying database.

A table pool corresponds to a table in the database in which all records from the pooled tables assigned to it are stored.

Several logical data records from different cluster tables can be stored together in one physical record in a table cluster.

A pooled table cannot have the name having more than 10 characters.

All the key fields of the pooled table must be of character data type.

In pooled tables, the maximum length of the key field/data fields should not exceed the length of varkey/vardata of the pool respectively.

In cluster table the records having the same key are stored in a single key in the cluster.

If there is an overflow of the data records a continuation record is created with the same table key.

[Former Member]

Hi,

when we add a field MANDT of type MANDT then our table is client dependent

and is visible to only that client. But if this Field is not added to the

table then we can access the table using any client number.

tables which can be access by all user are client independent (no mandt field in table)

tables which can be access by some specific user are client dependent (use mandt field in table)

Table pools (pools) and table clusters (clusters) are

special table types in the ABAP Dictionary. The data from

several different tables can be stored together in a table

pool or table cluster. Tables assigned to a table pool or

table cluster are referred to as pooled tables or cluster

tables.

Table Pools

===========

A table pool or table cluster should be used exclusively for

storing internal control information (screen sequences,

program parameters, temporary data, continuous texts such as

documentation). Data of commercial relevance is usually

stored in transparent tables.

A table in the database in which all records from the pooled

tables assigned to the table pool are stored corresponds to

a table pool.

Table Clusters

==============

Several logical data records from different cluster tables

can be stored together in one physical record in a table

cluster.

A cluster key consists of a series of freely definable key

fields and a field (Pageno) for distinguishing continuation

records. A cluster also contains a long field (Vardata) that

contains the contents of the data fields of the cluster

tables for this key. If the data does not fit into the long

field, continuation records are created.

with regards,

sowjanya.gosala.

[Former Member]

Hi,

Tables having 'MANDT' as one of the primary key is a client dependent table. And those tables which are linked to other table throught Foreign Key relationships are called Dependedt table.

The following documentation below will be helpful.

The following are the table types used in SAP :

Transparent Tables

There is a physical table on the database for each transparent table.

The names of the physical table and the logical table definition in the

ABAP/4 Dictionary agree. All the business and application data is store

in transparent tables.

Pooled table

Pooled tables can be used to store control data (e.g. screen sequences,

program parameters or temporary data). Several pooled tables can be

combined to form a table pool. The table pool corresponds to a physical

table on the database in which all the records of the allocated pooled

tables are stored.

Cluster table

Cluster tables contain continuous text, for example documentation.

Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table category. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least part of the keys must agree. Several cluster tables are stored in one corresponding table on the database.

I. Transparent tables (BKPF, VBAK, VBAP, KNA1, COEP)

Allows secondary indexes (SE11->Display Table->Indexes)

Can be buffered (SE11->Display Table->technical settings) Heavily updated tables should not be buffered.

II. Pool Tables (match codes, look up tables)

Should be accessed via primary key or

Should be buffered (SE11->Display Table->technical settings)

No secondary indexes

Select * is Ok because all columns retrieved anyway

III. Cluster Tables (BSEG,BSEC)

Should be accessed via primary key - very fast retrieval otherwise very slow

No secondary indexes

Select * is Ok because all columns retrieved anyway. Performing an operation on multiple rows is more efficient than single row operations. Therefore you still want to select into an internal table. If many rows are being selected into the internal table, you might still like to retrieve specific columns to cut down on the memory required.

Statistical SQL functions (SUM, AVG, MIN, MAX, etc) not supported

Can not be buffered

IV. Buffered Tables (includes both Transparent & Pool Tables)

While buffering database tables in program memory (SELECT into internal table) is generally a good idea for performance, it is not always necessary. Some tables are already buffered in memory. These are mostly configuration tables. If a table is already buffered, then a select statement against it is very fast. To determine if a table is buffered, choose the 'technical settings' soft button from the data dictionary display of a table (SE12). Pool tables should all be buffered.

Tables Documentation

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/25c1f5d1-0901-0010-d495-e96d02a0...

Best Regards,

Rajesh.

Please reward points if found helpful.

[Former Member]

The client field must be included for client-dependent tables/views.

Overview of the DB table types

In addition to transparent tables, where the definition in the ABAP Dictionary and

in the database are identical, there are pool and cluster tables in the R/3 system.

Pool and cluster tables are characterized by the fact that several tables logically

defined in the ABAP Dictionary are combined in a physical database table (table

pool or cluster).

Pool tables

The basic idea of a table pool, as opposed to table clusters, is the storage of data

records from the tables defined in the ABAP Dictionary that are not dependent on

one another. You would like to combine small R/3 tables to a database table.

In the example above, you can recognize that the intersection of the key fields of

TABA and TABB is empty. Despite this, the data records from TABA and TABB

are stored in the TABAB table pool.

The key for a data record of the TABAB table pool consists of both the fields

TABNAME and VARKEY. The TABNAME field assumes the name of the pool

table. The VARKEY field consists of the concatenation of the key fields of the

pool table. This arises in the necessity that the key fields of a pool table must

be of the type C.

In the VARDATA field, the non-key fields of the pool tables are stored in an

unstructured way, in compressed form by the database interface. The DATALN

field contains the length of the VARDATA field.

Cluster tables

The idea of cluster tables is that you store functionally dependent data which is

divided among different tables in one database table. Accordingly, the intersection

of the key fields of the cluster tables is formed by the key of the table cluster

(cluster key).

The data dependent on one cluster key are stored in the VARDATA field of the

table cluster. If the VARDATA field does not have the capacity to take on all

dependent data, the database interface creates an overflow record. The uniqueness

within the table cluster is guaranteed by the PAGNO field.

The content of the VARDATA field is compressed by the databse interface.

Accordingly, the VARDATA field contains a description for decompressing its

data. The TIMESTAMP and PAGELG fields contain administrative information.

The advantages and disadvantages of pool and cluster tables:

1.The decisive advantage of pool and cluster tables is that the data can be stored

in compressed form in the database. This reduces the memory space required

as well as the network load.

2.The combination of tables into table pools to table clusters means less tables and

the compressing means less fields in the database. The result is that fewer different

SQL statements are carried out.

3.Pool and cluster tables are not stored as separate tables in the database. In this way,

the administration becomes simpler. With cluster tables, functionally dependent

data are read together, which results in fewer database accesses.

4.The decisive disadvantage lies in the restricted database functionality. It is not

possible for non-key fields to create an index. There are neither primary indices

nor indices on a subset of the key fields. The use of database views or ABAP

JOINs is also ruled out, as are Table Appends. You can access the data in pool or

cluster tabels only via OPEN SQL (no Native SQL).

5.For pool tables, only the WHERE conditions for key fields and for pool tables,

only the WHERE conditions for the fields of the cluster key (subset of the key

fields) are transferred to the database. ORDER BY (or GROUP BY) clauses

are not transferred for non-key fields. You need longer keys than semantically

necessary for pool tables.