In the SAP dictionary there are three types of database tables:
– transparent table
– pooled table
– clustered table
For a transparent table there is an exact 1:1 relation between dictionary and database. If a table exists in the SAP dictionary with name “TABXYZ” and fields “MANDT”, “COL1” and “COL2”, then you will also find a database table named TABXYZ with fields MANDT, COL1 and COL2. The data type of a field in the dictionary is mapped to a data type of the underlying database system, e.g. with Oracle a field with type CHAR(n) in the dictionary becomes VARCHAR2(n) in the database.
A pooled table does not exist as a separate database table. Instead, groups of pooled tables are stored together inside a physical pool. At the database level there is only one table (namely the physical pool). This table has a field called TABNAME, which contains the name of the “logical” (i.e. pooled table) that each specific row belongs to. You can see this in the SAP dictionary: in SE12, enter “ATAB” as the table name and look at the structure. ATAB is the most important physical pool in the SAP database; in ECC 6 systems ATAB contains over 1800 pooled tables. The actual columns of a pooled table are not visible at database level: they are grouped together in the phsyical pool columns VARKEY (for the primary key fields) and VARDATA (non-key fields); both columns are of raw (binary) type. The database interface of the SAP kernel takes care of converting between these binary containers and the logical field names as defined in the dictionary.
Like pooled tables, clustered tables do not exist as separate database tables; they are part of a physical cluster. At the database level only the physical cluster exists as a table. Whereas with pooled tables, one row of the pool belongs uniquely to one logical table, one row of a physical cluster contains data of several clustered tables. The idea is that data of a “master” table is kept physically together with data of “subordinate” tables that share a cmmon primary key. This is beneficial for performance. Because the combination of the “header” row with its subordinate records may exceed the maximum size of a physical row in the cluster, the rows for a common key have a sequence number. You can for example look in SE12 at the cluster RFBLG (a cluster containing accounting tables). The first four fields of RFBLG (MANDT, BUKRS, BELNR, GJAHR) define the common part of the primary key of the master and subordinate tables. PAGENO is the sequence number. TIMESTMP is an internal timestamp, PAGELG the length of the page (binary data) and VARDATA holds the actual data in binary form. PAGENO, TIMESTMP, PAGELG and VARDATA exist in all clusters; the fields coming before this (common key fields) are specific to each cluster.
Transparent tables form the overwhelming majority. In the ECC 6 system I have here, there are 69984 transparent tables, 2019 pooled tables and just 77 clustered tables. That does not mean that they are unmiportant: pooled tables are often small but critical (mostly customizing) tables; and some of the most critical tables in the system are clustered, e.g. the core accounting table (BSEG, clustered inside RFBLG) or the change document tables CDPOS and PCDPOS (in physical cluster CDCLS).
I hope this clarifies things (at least if I got your question right
Domain is the central object for describing the technical characteristics of an attribute of an business objects. It describes the value range of the field.
It is used to describe the semantic definition of the table fields like description the field. Data element describes how a field can be displayed to end-user.
Check tables APQD, APQI and APQL. To read the log, check the program RSBDC_ANALYSE;
Domains describes the technical characteristics of a table field.
Specifies a value range which describes allowed data values for the fields
Fields referring to the same domain (via the data elements assigned to them) are changed when a change is made to the domain
Domain can be assigned to multiple data element but vice versa is not possible.
If we do not assign domain to a dataelement it is still valid.
But the disadvantage will be the value range will not be obtained.
Batch Input Session is created to transfer data from outside world to SAP through screen sequences and field validations just like manual entry of the data using transaction code.
The alternatives to batch input session are (1) Call Transaction Method (2) Direct Input through SAP delivered Programs (3) BAPIs (Preferred method)
Batch Input Sessions can be processed in background using the program RSBDCSUB.
below the typical structure…
The vendor data stored in various tables. If u want to change the one particular thing (In u r case Country code).The changes need to effect the all the tables. So for that reason u can go to the tcode (XK02) for changing the vendor information.
If some thousands of vendors are need to change the country code. In that u need to do for recording for
one vendor using SHDB tcode.
In report porgram write BDC code to vhange all vendors country codes.
Some of the IQS about BDC:
1 What should be the approach for writing a BDC program?
Ans.: 1. Analysis the Data. 2. Generate SAP structure. 3. Develop transfer program 4. Create sequential file. 5. Create batch input program. 6. Process batch input data
2) What are the steps in a BDC session ?
The first step in a BDC session is to identify the screens of the transaction that the program will process. Next step is to write a program to build the BDC table that will be used to submit the data to SAP. The final step is to submit the BDC table to the system in the batch mode or as a single transaction by the CALL TRANSACTION command.
3)What are the function modules associated with batch input?
Ans :- BDC_OPEN_GROUP , BDC_CLOSE_GROUP , BDC_INSERT.
4)How do you find the transaction number, program number and field names?
Transaction no.,program no.
THESE ARE SOME DIFFERENCE POINTS.
1. Transparent tables have one to one relation ship ie., the structure which defined in the data dictionary level(here we define the tables etc..) is same as in database level(here the data is stored physically).
2. we usually create transparent tables only.
3. In cluster and pooled tables they have many to one relationship ie., they have many structures or definitions at dictionary level but a single table in database level.
4. Major difference is cluster tables must have at least one primary key common but in pooled they may have or may not have a primary key in common.
5. We don