Generic extractors on pool table and Cluster tables

Good Afternoon all,
Can we create generic extractors on Cluster or pool Table. If yes Let me know how?
I am trying to create a Generic Extractor on BSEC Table but it is not allowing me to do this. It throws error that"Extraction from pool tables and cluster tables is not permitted"
Kindly guide me on this
Thanks,
Vaishali.

Hi
you cannot do generic extraction directly on pooled or cluster tables.
You can create a function module, then you can create a Generic Data source based on this..
Hope it helps,
Thanks,
Teja
Edited by: Teja badugu on Apr 15, 2008 12:24 PM

Similar Messages

How can I get data in flat file from Pool table and cluster table ?

Hi,
I am working in one Achiving project. My requirement is to get data into flat file from Cluster table and pool table.
Is there any tool avilable to download data into flat file from pool table and cluster table ?
if table name given in the selection screen then data will be downloaded into flat file.
waiting for quick response.
Best Regards,
Bansidhar

Data cannot be retrived directly form the cluster table
as the Cluster results are stored in Cluster Key say for example PCLkey
and form that Key we need to fetch the data
these clustes are not the part of PNP or PNPCE tables
for ur info kindly check

Inforation on Pool tables and cluster tables required.

I want to know about the pool tables and cluster tables like how to create them and how to look the tables associated with the given tables. Like for the table BSEG we have other tables linked BSID etc. I'm new to this concept please guide me.

Pooled Table:
A pooled table in R/3 has a many-to-one relationship with a table in the database (see Figures 3.1 and 3.2). For one table in the database, there are many tables in the R/3 Data Dictionary. The table in the database has a different name than the tables in the DDIC, it has a different number of fields, and the fields have different names as well. Pooled tables are an SAP proprietary construct.
When you look at a pooled table in R/3, you see a description of a table. However, in the database, it is stored along with other pooled tables in a single table called a table pool. A table pool is a database table with a special structure that enables the data of many R/3 tables to be stored within it. It can only hold pooled tables.
R/3 uses table pools to hold a large number (tens to thousands) of very small tables (about 10 to 100 rows each). Table pools reduce the amount of database resources needed when many small tables have to be open at the same time. SAP uses them for system data. You might create a table pool if you need to create hundreds of small tables that each hold only a few rows of data. To implement these small tables as pooled tables, you first create the definition of a table pool in R/3 to hold them all. When activated, an associated single table (the table pool) will be created in the database. You can then define pooled tables within R/3 and assign them all to your table pool.
Pooled tables are primarily used by SAP to hold customizing data.
Cluster Table:
A cluster table is similar to a pooled table. It has a many-to-one relationship with a table in the database. Many cluster tables are stored in a single table in the database called a table cluster.
A table cluster is similar to a table pool. It holds many tables within it. The tables it holds are all cluster tables.
Like pooled tables, cluster tables are another proprietary SAP construct. They are used to hold data from a few (approximately 2 to 10) very large tables. They would be used when these tables have a part of their primary keys in common, and if the data in these tables are all accessed simultaneously.
Table clusters contain fewer tables than table pools and, unlike table pools, the primary key of each table within the table cluster begins with the same field or fields. Rows from the cluster tables are combined into a single row in the table cluster. The rows are combined based on the part of the primary key they have in common. Thus, when a row is read from any one of the tables in the cluster, all related rows in all cluster tables are also retrieved, but only a single I/O is needed.
A cluster is advantageous in the case where data is accessed from multiple tables simultaneously and those tables have at least one of their primary key fields in common. Cluster tables reduce the number of database reads and thereby improve performance.
Restrictions on Pooled and Cluster Tables
1. Pooled and cluster tables are usually used only by SAP and not used by customers, probably because of the proprietary format of these tables within the database and because of technical restrictions placed upon their use within ABAP/4 programs. On a pooled or cluster table:
2. Secondary indexes cannot be created.
3. You cannot use the ABAP/4 constructs select distinct or group by.
4.You cannot use native SQL.
5.You cannot specify field names after the order by clause. order by primary key is the only permitted variation.
For creation of pooled /cluster table, have a look at below link.
http://help.sap.com/saphelp_erp2004/helpdata/en/81/415d363640933fe10000009b38f839/frameset.htm
For creation of table pool /cluster, have a look at below link.
http://help.sap.com/saphelp_erp2004/helpdata/en/81/415d363640933fe10000009b38f839/frameset.htm
Have a look at below link.
http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm
Best Regards,
Vibha
*Please mark all the helpful answers

What is the differences between Transparent,Pooled and Cluster tables?

Hello all,
What is Pool table?What is the differences between Transparent,Pooled and Cluster tables?
Regards!
Purna

Transparent table:
Tables can be defined independently of the database in the ABAP Dictionary. The fields of the table are defined together with their (database-independent) data types and lengths.
A table definition in the ABAP Dictionary has the following components:
Table fields: The field names and the data types of the fields contained in the table are defined here.
Foreign keys: The foreign keys define the relationships between this table and other tables.
Technical settings: The technical settings define how the table is created on the database.
Indexes: Indexes can be defined for the table to speed up data selection from the table.
There are three categories of database tables in the ABAP Dictionary.
A physical table definition is created in the database for the table definition stored in the ABAP Dictionary for transparent tables when the table is activated. The table definition is translated from the ABAP Dictionary to a definition of the particular database.
On the other hand, pooled tables and cluster tables are not created in the database. The data of these tables is stored in the corresponding table pool or table cluster. It is not necessary to create indexes and technical settings for pooled and cluster 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 type. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least parts of the keys must agree. Several cluster tables are stored in one corresponding table on the database.
Regds,
Manohar

Can we create secondary indexes in pooled and cluster table?

hello all
can we create secondary indexes in pooled and cluster table?

Hi,
Yes, you can.
Refer the below links
[http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm|http://www.sap-img.com/abap/the-different-types-of-sap-tables.htm]
[http://help.sap.com/saphelp_40b/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm|http://help.sap.com/saphelp_40b/helpdata/en/cf/21f083446011d189700000e8322d00/content.htm]
Regards,
SB

Which type of information can be hold by pool and cluster tables

hi experts tell me exactly which type of information hold by pooled and cluster tables
thanks in advance

Hi
I hope, you know that Rewarding with Points for the Useful answers is the SDN policy
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.
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
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
Reward points for useful Answers
Regards
Anji

Replicating Pool and Cluster tables in HANA

Hi,
Has anyone been able to successfully replicate the Pool and Cluster tables to HANA? I browsed around but am not able to find any solid material/documents related to the same. Please point me to the same.
yogesh

Hi Yogesh,
Maybe you skiped this one. The sample uses BSEG from cluster RFBLG and it's very well explained by Tobias Koebler
How to enable parallel replication
Regards, Fernando Da Rós

Pooled table and clustred table

pooled table and clustred table

Hi
Pooled Tables, Table Pools, Cluster Tables, and Table Clusters
These types of tables are not transparent in the sense that they are not legible or manageable directly using the underlying database system tools. They are managed from within the R/3 environment from the ABAP dictionary and also at runtime when they are loaded into application memory.Pool and cluster tables are logical tables. Physically, these logical tables are arranged as records of transparent tables. The pool and cluster tables are grouped together in other tables, which are of the transparent type. The tables that group together pool tables are known as table pools, or just pools; similarly, table clusters, or just
clusters, are the tables which group cluster tables.Not all operations that can be performed over transparent tables can be executed over pool or cluster tables.
For instance, you can manage these tables using Open SQL calls from ABAP, but not Native SQL.These tables are meant to be buffered and loaded in memory, because they are commonly used for storing internal control information and other types of data with no external (business) relevance. SAP recommends that tables of pool or cluster type be used exclusively for control information such as
program parameters, documentation, and so on. Transaction and application data should be stored in transparent tables.
Table Pools
From the point of view of the underlying DBMS as from the point of view of the ABAP dictionary, a table pool is a transparent table containing a group of pooled tables which, when created, were assigned to this table pool.
Field Type Description
TABNAME CHAR(10) Table name
VARKEY CHAR(n) Maximum key length n =< 110
DATALN INT2(5) Length of the VARDATA record returned
VARDATA RAW(m) Maximum length of the data varies according to DBMS
Table Clusters
Similarly to pooled tables, cluster tables are logical tables which, when created, are assigned to a table cluster. Therefore, a table cluster, or just cluster, groups together several tables of type clusters.Several logical rows from different cluster tables are brought together in a single physical record. The records
from the cluster tables assigned to a cluster are thus stored in a single common table in the database.A cluster contains a transparent cluster key which must be located at the start of the key of all logical cluster tables to be included in the cluster. As well, a cluster contains a long field (VARDATA), which contains the
data of the cluster tables for this key. If the data does not fit into a field, continuation records are created.
Field Type Description
CLKEY1 CHAR(*) First key fields
CLKEY2 CHAR(*) Second key field
CLKEYN CHAR(*) nth key field
PAGENO INT2(5) Number of the next page
TIMESTMP CHAR(14) Time stamp
PAGELG INT2(5) Length of the VARDATA record returned
VARDATA RAW(*) Maximum length of the data section; varies according to database system
Working with Tables
The dictionary includes many functions for working with tables. There are five basic operations you can perform on tables: display, create, delete, modify, copy. Please do not confuse displaying a table with displaying the table entries (table contents). In order to display a table, it must previously exist; otherwise the system will display an error message in the status bar. For the following example, the table TABNA is used. To display this table, from the main dictionary screen, enter the table name in the Object name
input field with the radio button selected next to Tables. Then, click on the Display button at the bottom of the screen, or press the F7 function key, or, alternatively,
select Dictionary object Display from the menu.
In this screen, you can see table information such as
¨ Table type, shown next to the name of the object. In the example, it is a transparent table.
¨ Short text description.
¨ Name of the user who made the last change, and the date of the change.
¨ Master language.
¨ Table status. On the screen, you can see this table is saved and active.
¨ Development class. For information on development classes, refer to Chap. 6.
Delivery class, which sets the maintenance group for the table. It controls how tables will behave during client copy procedures, upgrades, and so forth.¨
Tab. Maint. Allowed flag, which indicates whether you can generate a screen for maintaining table entries.
¨Then, on the lower part of the screen, you can see the table fields with all associated characteristics such as:
¨ Field name.
¨ Key indicator. When set, this field is the primary key, or part of it.
¨ Data element.
¨ Basic data type.
¨ Length.
¨ Check table.
¨ Short text, describing the field.
Additional information about the table can be displayed by selecting the corresponding functions from the menu or directly from the application toolbar, such as keys, indexes, or technical settings
Standard table:
The key access to a standard table uses a sequential search. The time required for an access is linearly dependent on the number of entries in the internal table.
You should usually access a standard table with index operations.
Sorted table:
The table is always stored internally sorted by its key. Key access to a sorted table can therefore use a binary search. If the key is not unique, the entry with the lowest index is accessed. The time required for an access is logarithmically dependent on the number of entries in the internal table.
Index accesses to sorted tables are also allowed. You should usually access a sorted table using its key.
Hash table:
The table is internally managed with a hash procedure. All the entries must have a unique key. The time required for a key access is constant, that is it does not depend on the number of entries in the internal table.
You cannot access a hash table with an index. Accesses must use generic key operations (SORT, LOOP, etc.).
Index table:
The table can be a standard table or a sorted table.
Index access is allowed to such an index table. Index tables can be used to define the type of generic parameters of a FORM (subroutine) or a function module.
Just have a look at these links:
http://help.sap.com/saphelp_nw04/helpdata/en/90/8d7304b1af11d194f600a0c929b3c3/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/74/83015785d811d295a800a0c929b3c3/frameset.htm
For creating cluster tables first u have to create table pool ...
create a table and specify the fields and other tecnical settings and
then Goto EXTRAS --> Change Table Category and selct the Pooled table and activate it...
Then Create another table And specify the required fileds and also the settings and then
Goto EXTRAS --> Change Table Category and selct the Cluaster table and in Delivery and
Maintainence Properties mention the Pooled table that u created and activate it...
Regards
Sreeni

Difference between Temp table and Variable table and which one is better performance wise?

Hello,
Anyone could you explain What is difference between Temp Table (#, ##) and Variable table (DECLARE @V TABLE (EMP_ID INT)) ?
Which one is recommended to use for better performance?
also Is it possible to create CLUSTER and NONCLUSTER Index on Variable table?
In my case: 1-2 days transactional data are more than 3-4 Millions. I tried using both # and table variable and found table variable is faster.
Is that Table variable using Memory or Disk space?
Thanks Shiven:) If Answer is Helpful, Please Vote

Check following link to see differences b/w TempTable & TableVariable: http://sqlwithmanoj.com/2010/05/15/temporary-tables-vs-table-variables/
TempTables & TableVariables both use memory & tempDB in similar manner, check this blog post: http://sqlwithmanoj.com/2010/07/20/table-variables-are-not-stored-in-memory-but-in-tempdb/
Performance wise if you are dealing with millions of records then TempTable is ideal, as you can create explicit indexes on top of them. But if there are less records then TableVariables are good suited.
On Tables Variable explicit index are not allowed, if you define a PK column, then a Clustered Index will be created automatically.
But it also depends upon specific scenarios you are dealing with , can you share it?
~manoj | email: http://scr.im/m22g
http://sqlwithmanoj.wordpress.com
MCCA 2011 | My FB Page

How to convert Internal Table to Cluster Table ?

How to convert Internal Table to Cluster Table ?

Use :
EXPORT itab TO DATABASE dbtab(ar) ID key.
EXPORT obj1 ... objn TO DATABASE dbtab(ar) ID key.
Additions:
1. ... = f (for each field you want to export)
2. ... FROM f (for each field you want to export)
3. ... CLIENT g before ID key )
4. ... USING form
5. ... FROM wa (as last addition or after dbtab(ar))
In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Implicit field names not allowed with clusters and Table work areas not allowed.
Effect
Stores a data cluster in database table dbtab. The specified objects obj1 ... objn (fields, structures, or tables) are stored as a single cluster in the database table dbtab.
The specified database table dbtab must have a standard structure.
The database table dbtab is divided into various logically-related sections (ar, two-character name).
You can export a collection of data objects (a data cluster) to a part of the database using a key (field key).
You can import individual data objects from this collection using the IMPORT statement.
Notes
In classes, you must always assign explicit names to the data objects you want to export, that is, you must use either addition 1 or addition 2.
In classes, you must always specify the work area explicitly, that is, addition 5 is obligatory.
The table dbtab that appears after DATABAE must be declared under TABLES (except in addition 5).
You cannot export the header lines of internal tables. If you specify the name of an internal table with header line, the system always exports the body of the table.
You cannot export data, object, or interface references.
The data is stored in the database, and is consequently not actually stored until a database commit occurs (see LUW). Until this point, you can undo all of your changes using a database rollback (see Programming Transactions).
Example
Exporting two fields and an internal table to the database table INDX:
TABLES INDX.
TYPES: BEGIN OF ITAB3_TYPE,
 CONT(4),
 END OF ITAB3_TYPE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
 F1(4), F2 TYPE P,
 ITAB3 TYPE STANDARD TABLE OF ITAB3_TYPE WITH NON-UNIQUE
 DEFAULT KEY INITIAL SIZE 2,
 WA_INDX TYPE INDX.
Fill the data fields before CLUSTR
before the actual export
INDX-AEDAT = SY-DATUM.
INDX-USERA = SY-UNAME.
Export der Daten.
EXPORT F1 FROM F1
 F2 FROM F2
 ITAB3 FROM ITAB3
 TO DATABASE INDX(ST) FROM WA_INDX ID INDXKEY.

Regards

Fact Table and Dimension Tables

Hi Experts, I'm creating custom InfoCubes for data coming from non-SAP source systems. I have two InfoCubes. Tha data is coming from like 10 tables. I have 10 DataSources created fo this and the data will be consolidated in Standard DSO before it will flow into 2 InfoCubes.
Now client wants to know before how much data will be there in InfoCubes in Fact table nad Dimension tables in both the InfoCubes. I have the total size of all the 10 tables from the sources given to me by the DBA. I wan not sure how I can convert that info for Fact table and Dimension table as I have not yet created these Infocubes.
Please help me with this on how I should address this.

hi,
The exact data will be hard to give however you can reach at a round figure in your case.
You are consolidating the data from the tables that means that there is relation between the tables. Arrive at a rough figure based on the relation and the activity you are performing while consolidating the data of the tables.
For example, let us say we want to combine data for sales order and deliveries in a DSO.
Let Sales order has 1000 records and Delivery has 2000 records. Both the tables have a common link (Sales Order).In DSO you are combining the data that means the data will be at the most granular level consist of Delivery data, so the maximum no of records which the consolidated DSO can have is 2000.
regards,
Arvind.

Reg: Fact table and Dimension table in Data Warehousing -

Hi Experts,
I'm not exactly getting the difference between the criteria which decide how to create a Fact table and Dimension table.
This link http://stackoverflow.com/questions/9362854/database-fact-table-and-dimension-table states :
Fact table contains data that can be aggregate.
Measures are aggregated data expressions (e. Sum of costs, Count of calls, ...)
Dimension contains data that is use to generate groups and filters.
This's fine but how does one decide which columns to consider for Fact table and which columns for Dimension table?
Any help is much appreciated.
Pardon me if this's not the correct place for this question. My first question in the new forum.
Thanks and Regards,
Ranit Biswas

ranitB wrote:
But my main doubt was - what is the criteria to differentiate between columns for Fact tables and Dimension tables? How can one decide upon the design?
Columns of a fact table will often be 'scalar' attributes of the 'fact' data item. A dimension table will often be 'compound' attributes of a 'fact'.
Consider employee information. The EMPLOYEE table can be a fact table. It might have scalar attribute columns such as: DATE_HIRED, STATUS, EMPLOYEE_ID, and so on.
Other related information that can't be specified as a single attribute value would often be stored in a 'dimension' table: ADDRESS, PHONE_NUMBER.
Each address requires several columns to define it: ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY. And an employee might have several addresses: WORK_ADDRESS, HOME_ADDRESS. That address info would be stored in a 'dimension' table and only the primary key value of the address record would be stored in the EMPLOYEE 'fact' table.
Same with PHONE_NUMBER. Several columns are required to define a phone number and each employee might have several of them. The dimension tables are used to help 'normalize' the data in the employee 'fact' table.
And that EMPLOYEE table might also be a DIMENSION table for other FACT tables. A DEVELOPER table might have an EMPLOYEE_ID column with a value that points to a 'dimension' row in the EMPLOYEE dimension table.

DATA BASE TABLE AND INTERNAL TABLE

Dear Friends,
please help me out in getting complete information about database table and internal table.
you can email me at < Removed by moderator - please maintain e-mail iDs in Business Card>
Message was edited by:
Arun Varadarajan

Hi Hazi,
DATABASE Tables :
This are the tables which are stored in the database (eg Oracle , informix , DB2 etc..) Physically. u can view it from T-codes SE11 or SE16. here in SE11 u can create ur own Transparent table.
for more information...
http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/dictionary_tutorial.html
Internal Tables.
While generating reports or other objects we are not modifying the database tables directly first we are selecting the data of the database table into the internal tables... so that we can reduce the database access time and network traffic .. which is highly needed in R/3 system..
internal tables are not exist phyiscally in the system. its like a array. the existance of the internal tables is upto the program execution in which u r declaring nd using it...
for more information..
http://www.sapbrainsonline.com/TUTORIALS/TECHNICAL/internaltables_tutorial.html
Hope it will solve ur problem..
Reward points if useful..
Thanks & Regards
ilesh 24x7

Check table and value table -Example

Hi Experts
Please give me the step by step procedure to create the check table and value table, and how to work on it.
Thanks in advance.
Regards
Rajaram

Hi
Check Table is for Field level Validation whereas Value table is for Domain Level Validations.
Value Table proposes table for check table.
I think you are clear with this.
more elaborate.
Check Table
The Check Table is the table used by system to check if a data exist or not exist.
While creating a table if you want to be sure that a field can have some values
and these are in a certain table, you can give IT this table as CHECK TABLE.
Value Table
This is maintained at Domain Level.
When ever you create a domain , you can entered allowed values. For example you go to Domain SHKZG - Debit/credit indicator.
Here only allowed values is H or S.
When ever you use this Domain, the system will forces you to enter only these values.
This is a sort of master check . .
To be maintained as a customization object.
This mean that if you want to enter values to this table you have to create a development request & transport the same.
Differences:
1)check table will carry out the check for input values for the table field being entered in any application
and value table will provide values on F4 help for that table field.
2)The check table defines the foreign keys and is part of the table definition.
The value table is part of the domain definition.
check table is validation at field level.
value table is at domain level.
Value table is defined at the domain level and is used to provide F4 help for all the fields which refer to that domain.
Check table is defined against a field in SE11 if you want the values in that field to be checked against a list of valid values. For e.g. if you are using the field matnr in a table you could define MARA as the check table.
Also while defining a check table SAP proposes the value table as check table by default. Referring to the previous example if you tried to define a check table for the matnr field SAP would propose MARA as the check table.
1. what is the purpose / use ?
-- so that the user can select values
from some master table , for that field !!!!
2. This is done by
CHECK TABLE (foreign key concept)
(and not value table)
3. When we create a check table for a field,
then
some DEFAULT table is PROPOSED
4. that DEFAULT table is nothing
but PICKED up from the domain of that field,
and shown from the value of VALUE TABLE.
CHECK TABLE -it is a parent table.
for example..
i have two tables ZTAB1 and ZTAB2.
I have one common field in both the tables,i can make any ztable to be the check table .If i make Ztab1 to be the check table then when i have to make an entry in ztab2 i will check whether ztab1 is having that value or not..
its also field level checking..
Valuetable-It is nothing but default check table.
one parent can have n number of child tables.For example
For ztable we have zchild1 and zchild2 tables r there.
Its domain level checking..When zchild2 uses the same domain as used by zchild1 then the system automatically generates a popup saying a check table already exists would u want to maintain it.
go to domain and then press the value tab u can see the valuetable at the end...
Please refer the links below,
d/r b/n check and value table?
wjhat is the exct difference between check table and value table
what is the check table and value table
check table and value table
Re: wjhat is the exct difference between check table and value table
http://www.sap-img.com/abap/difference-between-a-check-table-and-a-value-table.htm

Number of Entries in Dimension Tables and Fact Tables

Hi all,
is there an easy way to check
- the number of entries in the dimension tables
- the number of entries in the fact table?
Thanks a lot
Alex

Hi Alex,
If u want to see the content of Dimension table and Fact table for a infocube then just right click on a particular info cube then select manage . Select coneten tab there , form there u can either select Fact table to see the fact table conten or Infocube content to see the Dimensiontable content.
Regards..

Generic extractors on pool table and Cluster tables

Similar Messages

Maybe you are looking for