Sep 20, 2008
Internal table
Purpose of Internal Tables
• In ABAP/4, you work mainly with tables. Tables are the essential data structures in the R/3 System. Long-life data is stored in relational database tables.
• Besides database tables, you can create internal tables which exist only during the runtime of your program. ABAP/4 provides various operations for working with internal tables. You can, for example, search for, append, insert, or delete lines.
• The number of lines in an internal table is not fixed. Depending on requirements, the system increases the size of internal tables at runtime.
• You can use internal tables to perform table calculations on subsets of database tables. For example, you can read a certain part of a database table into an internal table (see Reading Data into an Internal Table).
From the internal table, you can then calculate totals or generate a ranked list.
• Another use for internal tables is reorganizing the contents of database tables according to the needs of your program. For example, you can read data relevant for creating a telephone list from one or several large customer tables into an internal table. During the runtime of your program, you can then access this list directly without having to perform a time-consuming database query for each call.
Structure of Internal Tables
In ABAP/4, you can distinguish between internal table data types, which define the structure of internal tables, and internal table data objects, which are the actual internal tables and can be filled with data. An internal table data type is an abstract definition of a data structure which can be used to declare data objects as internal tables.
Data type
An internal table is one of the two structured data types in ABAP/4. The other structured data type is the field string. An internal table consists of any number of lines which all have the same data type. The data type of the lines can be elementary or structured.
This definition opens a variety of internal table structures which range from lines consisting of one field to lines consisting of field strings which have internal tables as components.
You can define a data type as an internal table by using the TYPES statement with the OCCURS parameter. No memory is occupied when defining a data type.
Data object
A data object which has a data type defined as an internal table is the actual internal table you work with. It occupies memory and you can fill or read its lines.
You create a data object as an internal table by using the DATA statement either with the OCCURS parameter or by referring to another internal table by using the TYPE or LIKE parameters.
Identifying Table Lines
In order to access a certain line of a table, you must specify a field or combination of fields that can be used to identify the line. In the relational data model which is used to store long-life data in the R/3 System, the minimum combination required for this purpose is known as the key. The fields that define the key are called key fields.
Internal Table Index
The index is the sequential number of a table line. It is not a table field, but is created and managed automatically by the system.
You can use the index with the DELETE, INSERT, MODIFY, LOOP, and READ statements. In these statements, you can specify the index either as literal or as variable.
After processing a particular line of an internal table, the system field SY-TABIX generally contains the index of that line.
Internal Table Key
There are two kinds of internal table keys.
Self-defined Key
When reading lines from an internal table using the READ statement, you can specify a self-defined.
Standard Key
By definition, the key fields of an internal table are those fields which are not numeric (type F, I, and P) and are not internal tables. These key fields form the standard key of an internal table.
To obtain the standard key of an internal tables with nested structures (table lines which contain field strings as components), the system breaks down the sub-structures to the level of elementary fields.
• In ABAP/4, you work mainly with tables. Tables are the essential data structures in the R/3 System. Long-life data is stored in relational database tables.
• Besides database tables, you can create internal tables which exist only during the runtime of your program. ABAP/4 provides various operations for working with internal tables. You can, for example, search for, append, insert, or delete lines.
• The number of lines in an internal table is not fixed. Depending on requirements, the system increases the size of internal tables at runtime.
• You can use internal tables to perform table calculations on subsets of database tables. For example, you can read a certain part of a database table into an internal table (see Reading Data into an Internal Table).
From the internal table, you can then calculate totals or generate a ranked list.
• Another use for internal tables is reorganizing the contents of database tables according to the needs of your program. For example, you can read data relevant for creating a telephone list from one or several large customer tables into an internal table. During the runtime of your program, you can then access this list directly without having to perform a time-consuming database query for each call.
Structure of Internal Tables
In ABAP/4, you can distinguish between internal table data types, which define the structure of internal tables, and internal table data objects, which are the actual internal tables and can be filled with data. An internal table data type is an abstract definition of a data structure which can be used to declare data objects as internal tables.
Data type
An internal table is one of the two structured data types in ABAP/4. The other structured data type is the field string. An internal table consists of any number of lines which all have the same data type. The data type of the lines can be elementary or structured.
This definition opens a variety of internal table structures which range from lines consisting of one field to lines consisting of field strings which have internal tables as components.
You can define a data type as an internal table by using the TYPES statement with the OCCURS parameter. No memory is occupied when defining a data type.
Data object
A data object which has a data type defined as an internal table is the actual internal table you work with. It occupies memory and you can fill or read its lines.
You create a data object as an internal table by using the DATA statement either with the OCCURS parameter or by referring to another internal table by using the TYPE or LIKE parameters.
Identifying Table Lines
In order to access a certain line of a table, you must specify a field or combination of fields that can be used to identify the line. In the relational data model which is used to store long-life data in the R/3 System, the minimum combination required for this purpose is known as the key. The fields that define the key are called key fields.
Internal Table Index
The index is the sequential number of a table line. It is not a table field, but is created and managed automatically by the system.
You can use the index with the DELETE, INSERT, MODIFY, LOOP, and READ statements. In these statements, you can specify the index either as literal or as variable.
After processing a particular line of an internal table, the system field SY-TABIX generally contains the index of that line.
Internal Table Key
There are two kinds of internal table keys.
Self-defined Key
When reading lines from an internal table using the READ statement, you can specify a self-defined.
Standard Key
By definition, the key fields of an internal table are those fields which are not numeric (type F, I, and P) and are not internal tables. These key fields form the standard key of an internal table.
To obtain the standard key of an internal tables with nested structures (table lines which contain field strings as components), the system breaks down the sub-structures to the level of elementary fields.
LUW - Logical Unit of Work
An SAP logical unit of work (LUW) is a functionally complete set of steps within a business process in the R/3 System.
The process steps must be logically related.
SAP LUWs work on an all-or-nothing principle: Either all or none of its steps are carried out.
The business process to be mapped must be basic. For example, you would not have a single SAP LUW consisting of all of the steps between a customer processing an order and an invoice being produced. Instead, you would split this up into separate parts, each of which would then be represented in the R/3 System by its own LUW. What constitutes an "elementary" process depends on the overall process and how you have modeled it.
For further information, see the ABAP Editor Keyword documentation for the term transaction processing.
A database logical unit of work (LUW) is a non-separable sequence of database operations. At the beginning and end of the LUW, the database is in a consistent state.
The database LUW is either fully carried out by the database system, or is not carried out at all.
A database LUW is opened with every dialog step and by a database commit of the previous DB LUW.
The database LUW is closed with a database commit. It is only in the commit that the data is written to the database (after which it can no longer be reversed). Before the database commit, you can undo the changes using a database rollback. Here, the database is reset to the status that it had before the first change was made to the current DB LUW.
Data that has been written to the database permanently with a database commit cannot be rolled back.
Database LUWs allow you to encapsulate logically related actions from a business process. For example, when transferring sums of money in financial accounting, you must deduct an amount from one account and then add it to another account. Before and after the process, the data is consistent, but in between the two steps, it can be inconsistent.
For further information, see the ABAP Editor Keyword documentation for the term transaction processing.
The SAP R/3 System is based on the three-tier architecture of a client/server system. The three tiers are the database, application, and presentation server layers.
This architecture, along with the distribution of users' requests (user dispatching), leads to a highly efficient, cost-effective multi-user system.
The three-tier architecture means that a large number of users with low-cost desktop computers (with low performance) can be mapped to a small number of high-performance (and considerably more expensive) work processes on application servers. Each work process on an application server is assigned a work process on a high-performance database server.
Distributing user requests to work processes assigns individual clients at presentation server level to a work process for a particular period. In turn, the work process uses another work process in the database. After the work process has processed the user input in a dialog step, the user, along with the program context, is removed from the work process, which can then be used by another user.
The three-tier architecture is far more scalable than a "fat" client architecture, in which the Presentation and application levels run on one server. With three-tier architecture, the number of database users is considerably lower than the number of users active in the system. This has a positive effect on the behavior of the database.
The three-tier architecture of the R/3 System has certain consequences for process handling. When a work process is released for use by another user (client), an implicit database commit is triggered for the database process assigned to it (via a basis program).
Work processes on the application server and database are released before each user dialog. This Ensures that long user dialogs in which the system is "only displaying a screen" are not included in Database LUWs. The duration of the user interaction will be longer than the DB LUW duration.
Shorter database LUWs lead to less load on the database.
Implicit commits on the database are triggered whenever the work process has to wait. This includes:
When the system sends a new screen
When the system sends a dialog message
When you make a synchronous remote function call (RFC)
When you use the CALL TRANSACTION or SUBMIT statement.
Using an SAP LUW to represent a business process chain usually involves user dialogs as well as the changes to the database. The aim of an R/3 transaction is to represent the information exchanged in the SAP LUW as an indivisible unit in the database. This means that an SAP LUW can only use a single database LUW.
Since SAP LUWs usually involve several database LUWs, you need to bundle the database changes in a single database LUW within your transaction.
The process steps must be logically related.
SAP LUWs work on an all-or-nothing principle: Either all or none of its steps are carried out.
The business process to be mapped must be basic. For example, you would not have a single SAP LUW consisting of all of the steps between a customer processing an order and an invoice being produced. Instead, you would split this up into separate parts, each of which would then be represented in the R/3 System by its own LUW. What constitutes an "elementary" process depends on the overall process and how you have modeled it.
For further information, see the ABAP Editor Keyword documentation for the term transaction processing.
A database logical unit of work (LUW) is a non-separable sequence of database operations. At the beginning and end of the LUW, the database is in a consistent state.
The database LUW is either fully carried out by the database system, or is not carried out at all.
A database LUW is opened with every dialog step and by a database commit of the previous DB LUW.
The database LUW is closed with a database commit. It is only in the commit that the data is written to the database (after which it can no longer be reversed). Before the database commit, you can undo the changes using a database rollback. Here, the database is reset to the status that it had before the first change was made to the current DB LUW.
Data that has been written to the database permanently with a database commit cannot be rolled back.
Database LUWs allow you to encapsulate logically related actions from a business process. For example, when transferring sums of money in financial accounting, you must deduct an amount from one account and then add it to another account. Before and after the process, the data is consistent, but in between the two steps, it can be inconsistent.
For further information, see the ABAP Editor Keyword documentation for the term transaction processing.
The SAP R/3 System is based on the three-tier architecture of a client/server system. The three tiers are the database, application, and presentation server layers.
This architecture, along with the distribution of users' requests (user dispatching), leads to a highly efficient, cost-effective multi-user system.
The three-tier architecture means that a large number of users with low-cost desktop computers (with low performance) can be mapped to a small number of high-performance (and considerably more expensive) work processes on application servers. Each work process on an application server is assigned a work process on a high-performance database server.
Distributing user requests to work processes assigns individual clients at presentation server level to a work process for a particular period. In turn, the work process uses another work process in the database. After the work process has processed the user input in a dialog step, the user, along with the program context, is removed from the work process, which can then be used by another user.
The three-tier architecture is far more scalable than a "fat" client architecture, in which the Presentation and application levels run on one server. With three-tier architecture, the number of database users is considerably lower than the number of users active in the system. This has a positive effect on the behavior of the database.
The three-tier architecture of the R/3 System has certain consequences for process handling. When a work process is released for use by another user (client), an implicit database commit is triggered for the database process assigned to it (via a basis program).
Work processes on the application server and database are released before each user dialog. This Ensures that long user dialogs in which the system is "only displaying a screen" are not included in Database LUWs. The duration of the user interaction will be longer than the DB LUW duration.
Shorter database LUWs lead to less load on the database.
Implicit commits on the database are triggered whenever the work process has to wait. This includes:
When the system sends a new screen
When the system sends a dialog message
When you make a synchronous remote function call (RFC)
When you use the CALL TRANSACTION or SUBMIT statement.
Using an SAP LUW to represent a business process chain usually involves user dialogs as well as the changes to the database. The aim of an R/3 transaction is to represent the information exchanged in the SAP LUW as an indivisible unit in the database. This means that an SAP LUW can only use a single database LUW.
Since SAP LUWs usually involve several database LUWs, you need to bundle the database changes in a single database LUW within your transaction.
Few Technical definations..
1 Application Link Enabling (ALE)
The ALE concept supports the construction and operation of distributed applications.
The basic principle is the guarantee of a distributed, yet fully integrated, R/3 System installation.
It incorporates the controlled exchange of business data messages whilst ensuring data consistency across loosely coupled R/3 Systems.
The integration of various applications is achieved by using synchronous and asynchronous communication, rather than by means of a central database.
ALE comprises three layers:
• the applications services,
• the distribution services,
• the communications services.
2 Transaction Data
Transaction data is data that results from daily business management processes. Examples of transaction data are purchase order data and accounting data.
3 CO-PA
Abbreviation for Controlling - Profitability Analysis.
4 EDI - Electronic Data Interchange
Electronic Data Interchange is the electronic exchange of structured data (e.g. commercial documents) that is not limited to a single company, but which may take place between business partners at home or abroad who can be using different hardware, software and communication services.
5 Filter Object
A specific instance of the filter object type to which an organizational unit has been assigned, for example, "Plant" ® "Plant 0001".
6 Filter Object Type
A filter object type is a selection criterion in the distribution reference model that specifies the criteria which determine whether a function type can be used several times in a distributed system.
7 Function
A specific instance of a function type in the customer model.
8 Function Type
A function type defines a self-contained process in an application. An example of this is the posting for a movement of goods in inventory management.
9 Function Type, Distributable
A collection of function types which may be grouped together because of the related use of the various function types, and which may be seen as being distinct from other function types.
10 IDoc
Abbreviation of intermediate document (IDoc type )
11 IDoc Type - Intermediate Document Type
An intermediate document type is the structure of the data container used for transporting data from a system to a target system. It is independent of any specific application data.
12 Logical System
A logical system is a system in which different applications are integrated and run using common data. In SAP terms, this means a client in a database.
13 Information Structures
The most important key figures are selected from the mass of data arising from operational applications and are stored in special statistics files known as information structures. These include information on the time period, the characteristics and the key figures. An information structure can be distributed.
14 Key Figures
Key figures represent information that is periodically gathered or evaluated for characteristics (for example, lead time, deviation from schedule, capacity utilization, order stocks, quantities and rejects).
15 Bulk Processing
Several IDocs may be grouped into a packet and processed in a single step. This is called bulk processing.
16 Characteristic
A characteristic is a piece of information that can be used to effect a division in a group of objects, for example, plant, work center, material).
17 Message Type
The messages exchanged between systems are of various message types. The message type depends on the data contained and the process involved. It determines the technical structure of the message, the IDoc type. For example, the ORDERS message type is used for purchase order messages.
18 Periods
Periods include days, weeks, months and accounting periods.
19 Item Category
An item category is a classification that distinguishes between various types of item in, for example, an order (e.g. cost-free items, standard items). The way that processing is controlled depends on the item category.
20 Serialization
If several IDocs are sent within a short period of time then "overtaking" can occur, so that later changes arrive sooner than changes that were actually made earlier. In order to avoid incorrect updates being made, a serialization mechanism must be used that can spot "overtaking" and report it.
21 SOP
Sales & Operations Planning.
22 Customer Distribution Model
The customer stores the exact distribution of functions across his various systems in the customer distribution model. The logical systems and message flows are specified here, possibly based on defined listings.
23 Distribution Reference Model
The reference model is included in the standard delivery from SAP. It specifies which functions can be distributed and how, and which data is exchanged between the fucntions. The customer uses the reference model as the basis for his customer distribution model .
24 Workflow
A workflow is defined as a sequence of processing steps (work item ). There may be branching points within this sequence.
A workflow has a container. This holds the parameters used in the processing steps.
In order to terminate the processing steps of a workflow, an event is triggered. The parameters are passed from the current step to the workflow container.
The workflow manager checks which processing step should be called next. For example, if an 'Idoc read' step is terminated and a parameter indicating an error is passed, a step will be started that initiates manual processing.
An error will also cause an event to be triggered If a function module has been called directly. However, in contrast to the situation with a workflow, it does not cause a workflow step to be terminated, but rather an error workflow is started.
25 Work Item
A work item represents the run-time environment for a standard task that is defined once in the system. A standard task contains a method that can be used for processing a specific object.
The ALE concept supports the construction and operation of distributed applications.
The basic principle is the guarantee of a distributed, yet fully integrated, R/3 System installation.
It incorporates the controlled exchange of business data messages whilst ensuring data consistency across loosely coupled R/3 Systems.
The integration of various applications is achieved by using synchronous and asynchronous communication, rather than by means of a central database.
ALE comprises three layers:
• the applications services,
• the distribution services,
• the communications services.
2 Transaction Data
Transaction data is data that results from daily business management processes. Examples of transaction data are purchase order data and accounting data.
3 CO-PA
Abbreviation for Controlling - Profitability Analysis.
4 EDI - Electronic Data Interchange
Electronic Data Interchange is the electronic exchange of structured data (e.g. commercial documents) that is not limited to a single company, but which may take place between business partners at home or abroad who can be using different hardware, software and communication services.
5 Filter Object
A specific instance of the filter object type to which an organizational unit has been assigned, for example, "Plant" ® "Plant 0001".
6 Filter Object Type
A filter object type is a selection criterion in the distribution reference model that specifies the criteria which determine whether a function type can be used several times in a distributed system.
7 Function
A specific instance of a function type in the customer model.
8 Function Type
A function type defines a self-contained process in an application. An example of this is the posting for a movement of goods in inventory management.
9 Function Type, Distributable
A collection of function types which may be grouped together because of the related use of the various function types, and which may be seen as being distinct from other function types.
10 IDoc
Abbreviation of intermediate document (IDoc type )
11 IDoc Type - Intermediate Document Type
An intermediate document type is the structure of the data container used for transporting data from a system to a target system. It is independent of any specific application data.
12 Logical System
A logical system is a system in which different applications are integrated and run using common data. In SAP terms, this means a client in a database.
13 Information Structures
The most important key figures are selected from the mass of data arising from operational applications and are stored in special statistics files known as information structures. These include information on the time period, the characteristics and the key figures. An information structure can be distributed.
14 Key Figures
Key figures represent information that is periodically gathered or evaluated for characteristics (for example, lead time, deviation from schedule, capacity utilization, order stocks, quantities and rejects).
15 Bulk Processing
Several IDocs may be grouped into a packet and processed in a single step. This is called bulk processing.
16 Characteristic
A characteristic is a piece of information that can be used to effect a division in a group of objects, for example, plant, work center, material).
17 Message Type
The messages exchanged between systems are of various message types. The message type depends on the data contained and the process involved. It determines the technical structure of the message, the IDoc type. For example, the ORDERS message type is used for purchase order messages.
18 Periods
Periods include days, weeks, months and accounting periods.
19 Item Category
An item category is a classification that distinguishes between various types of item in, for example, an order (e.g. cost-free items, standard items). The way that processing is controlled depends on the item category.
20 Serialization
If several IDocs are sent within a short period of time then "overtaking" can occur, so that later changes arrive sooner than changes that were actually made earlier. In order to avoid incorrect updates being made, a serialization mechanism must be used that can spot "overtaking" and report it.
21 SOP
Sales & Operations Planning.
22 Customer Distribution Model
The customer stores the exact distribution of functions across his various systems in the customer distribution model. The logical systems and message flows are specified here, possibly based on defined listings.
23 Distribution Reference Model
The reference model is included in the standard delivery from SAP. It specifies which functions can be distributed and how, and which data is exchanged between the fucntions. The customer uses the reference model as the basis for his customer distribution model .
24 Workflow
A workflow is defined as a sequence of processing steps (work item ). There may be branching points within this sequence.
A workflow has a container. This holds the parameters used in the processing steps.
In order to terminate the processing steps of a workflow, an event is triggered. The parameters are passed from the current step to the workflow container.
The workflow manager checks which processing step should be called next. For example, if an 'Idoc read' step is terminated and a parameter indicating an error is passed, a step will be started that initiates manual processing.
An error will also cause an event to be triggered If a function module has been called directly. However, in contrast to the situation with a workflow, it does not cause a workflow step to be terminated, but rather an error workflow is started.
25 Work Item
A work item represents the run-time environment for a standard task that is defined once in the system. A standard task contains a method that can be used for processing a specific object.
Sep 19, 2008
SAP LOCK CONCEPT
SAP LOCK CONCEPT:
If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.
Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.
Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.
It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.
Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.
The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.
At the end of the database transaction, the database releases all of the locks that it has set during the transaction.
In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.
To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.
One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.
You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.
For further information, see the ABAP Editor Keyword documentation for the term Locking.
Logical locks are generated when an entry is written in the lock table. You use function modules to do this.
You can only set a lock if the relevant table entry is not already locked.
The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.
The SAP transaction can react appropriately by analyzing the return code.
Another user cannot gain access to work with the same table entries that are already locked.
Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).
If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X'
Messages.
When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.
The export parameters identify the table entry (or entries) that you want to lock.
The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.
If the lock could not be set; you should normally output an error message.
At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.
DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.
If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.
The lock table contains the lock arguments for each table (for lock arguments, see the following slide).
To display the lock table, use transaction SM12.
The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.
You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).
If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.
Lock entries must be assigned to a lock mode.
There are three different lock modes:
Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).
Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.
Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).
If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:
Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.
If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.
Lock attempts in other lock modes ('E' or 'X') are refused.
If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:
Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').
If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.
If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').
If a data record is locked in mode 'X', all further lock requests are refused.
If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:
First, lock the data that you want to edit.
Then read the current data from the database.
In the next step, process (change) the data in your program and write this to the database.
In the final step, release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).
Lock modules are created for lock objects and not tables.
Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".
A lock object is a logical object composed of a list of tables that are linked by foreign key
Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.
Example: A lock object that contains the tables SFLIGHT and SBOOK enables a flight with its bookings to be locked.
The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.
With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.
You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.
After you have assigned tables and default lock modes, lock objects must be generated.
When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.
These have the names ENQUEUE_ and DEQUEUE_ respectively.
If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:
1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).
If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.
Requesting a lock from a program is a communication step with lock administration. The
Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.
By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.
The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.
The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.
When the lock orders of a lock container can be executed, the lock container is deleted.
If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.
You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.
The specified function modules have release status internally-released.
If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.
Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.
Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.
It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.
Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.
The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.
At the end of the database transaction, the database releases all of the locks that it has set during the transaction.
In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.
To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.
One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.
You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.
For further information, see the ABAP Editor Keyword documentation for the term Locking.
Logical locks are generated when an entry is written in the lock table. You use function modules to do this.
You can only set a lock if the relevant table entry is not already locked.
The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.
The SAP transaction can react appropriately by analyzing the return code.
Another user cannot gain access to work with the same table entries that are already locked.
Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).
If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X'
Messages.
When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.
The export parameters identify the table entry (or entries) that you want to lock.
The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.
If the lock could not be set; you should normally output an error message.
At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.
DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.
If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.
The lock table contains the lock arguments for each table (for lock arguments, see the following slide).
To display the lock table, use transaction SM12.
The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.
You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).
If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.
Lock entries must be assigned to a lock mode.
There are three different lock modes:
Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).
Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.
Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).
If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:
Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.
If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.
Lock attempts in other lock modes ('E' or 'X') are refused.
If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:
Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').
If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.
If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').
If a data record is locked in mode 'X', all further lock requests are refused.
If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:
First, lock the data that you want to edit.
Then read the current data from the database.
In the next step, process (change) the data in your program and write this to the database.
In the final step, release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).
Lock modules are created for lock objects and not tables.
Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".
A lock object is a logical object composed of a list of tables that are linked by foreign key
Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.
Example: A lock object that contains the tables SFLIGHT and SBOOK enables a flight with its bookings to be locked.
The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.
With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.
You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.
After you have assigned tables and default lock modes, lock objects must be generated.
When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.
These have the names ENQUEUE_ and DEQUEUE_ respectively.
If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:
1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).
If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.
Requesting a lock from a program is a communication step with lock administration. The
Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.
By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.
The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.
The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.
When the lock orders of a lock container can be executed, the lock container is deleted.
If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.
You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.
The specified function modules have release status internally-released.
ABAP List Viewer
ABAP List Viewer
The common features of report are column alignment, sorting, filtering, subtotals, totals etc. To implement these, a lot of coding and logic is to be put. To avoid that we can use a concept called ABAP List Viewer (ALV).
Using ALV, we can have three types of reports:
1. Simple Report
2. Block Report
3. Hierarchical Sequential Report
There are some function modules which will enable to produce the above reports without much effort.
All the definitions of internal tables, structures
and constants are declared in a type-pool called SLIS.
Simple Report
The important function modules are:
•Reuse_alv_list_display
•Reuse_alv_fieldcatalog_merge
•Reuse_alv_events_get
•Reuse_alv_commentary_write
•Reuse_alv_grid_display
A. REUSE_ALV_LIST_DISPLAY: This is the function module which prints the data.
The important parameters are:
1. Export:
a. I_callback_program : report id
b. I_callback_pf_status_set : routine where a user can set his own pf status or change the
functionality of the existing pf -status.
c. I_callback_user_command : routine where the function codes are handled.
d. I_structure name : name of the dictionary table
e. Is_Layout : structure to set the layout of the report
f. It_fieldcat : internal table with the list of all fields and their attributes which are to
be printed (this table can be populated automatically by the function
module REUSE_ALV_FIELDCATALOG_MERGE)
g. It_events : internal table with a list of all possible events of ALVand their
corresponding routine names.
2. Tables:
a. t_outtab : internal table with the data to be output
B. REUSE_ALV_FIELDCATALOG_MERGE:
This function module is used to populate a fieldcatalog which is essential to display the data in ALV. If the output data is from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its enough to mention the table name as a parameter(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.
The important parameters are:
1. Export:
a. I_program_name : report id
b. I_internal_tabname : the internal output table
c. I_inclname : include or the report name where all the dynamic forms are handled.
2. Changing
ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV which is declared in
the type pool SLIS.
C . REUSE_ALV_EVENTS_GET: Returns table of possible events for a a list type
1. Import:
Et_Events : The event table is returned with all possible CALLBACK events for the
specified list type (column ‘NAME’). For events to be processed by the
callback, their ‘FORM’ field must be filled. If the field is initialized, the event
is ignored. The entry can be read from the event table, the field ‘FORM’ filled
and the entry modified using constants from the type pool SLIS.
2. Export:
I_list_type:
0 = simple list
1 = hierarchical-sequential list
2 = simple block list
3 = hierarchical-sequential block list
D. REUSE_ALV_COMMENTARY_WRITE : This is used in the Top-of-page event to print the headings and other comments for the list.
1. It_list_commentary : Internal table with the headings of the type slis_t_listheader.
This internal table has three fields:
Typ : ‘H’ - header, ‘S’ - selection, ‘A’ - action
Key : only when typ is ‘S’.
Info : the text to be printed
E. REUSE_ALV_GRID_DISPLAY: A new function in 4.6 version, to display the results in grid rather than as a list.
Parameters : same as reuse_alv_list_display
HIERARCHICAL REPORTS
A. REUSE_ALV_HIERSEQ_LIST_DISPLAY
1. Export:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
d. IS_LAYOUT
e. IT_FIELDCAT
f. IT_EVENTS
g. I_TABNAME_HEADER : Name of the internal table in the program containing the output data of the
highest hierarchy level.
h. I_TABNAME_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
i. IS_KEYINFO : This structure contains the header and item table field names which link the two tables
(shared key).
2. Tables
a. T_OUTTAB_HEADER : Header table with data to be output
b. T_OUTTAB_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
BLOCK REPORT
This is used to display multiple lists continuously.
The important functions used in this report are:
A. REUSE_ALV_BLOCK_LIST_INIT
B. REUSE_ALV_BLOCK_LIST_APPEND
C. REUSE_ALV_BLOCK_LIST_DISPLAY
D. REUSE_ALV_BLOCK_HS_LIST_APPEND
A. REUSE_ALV_BLOCK_LIST_INIT
Parameters:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
This function module is used to set the default GUI status etc.
B. REUSE_ALV_BLOCK_LIST_APPEND
Export :
a. IS_LAYOUT : layout settings for block
b. IT_FIELDCAT : field catalog
c. I_TABNAME : Internal table name of the output data
d. IT_EVENTS : internal table name with all possible events
Tables :
a. T_OUTTAB : internal table with output data.
This function module adds the data to the block.
INTERNAL TABLES IN SLIS
Slis_t_fieldcat_alv :
This internal table contains the field attributes. This internal table can be populated automatically by using ‘REUSE_ALV_FIELDCATALOG_MERGE’.
Important Attributes:
a. col_pos : position of the column
b. fieldname : internal fieldname
c. tabname : internal table name
d. ref_fieldname : fieldname (dictionary)
e. ref_tabname : table (dictionary)
f. key(1) : column with key-color
g. icon(1) : icon
h. hotspot(1) : hotspot
i. Symbol(1) : symbol
j. Checkbox(1) : checkbox
k. just(1) : (R)ight (L)eft (C)ent
l. do_sum(1) : sum up
m. no_out(1) : (O)blig. (X)no out
n. outputlen : output length
o. seltext-l : long key word
p. seltext_m : middle key word
q. seltext_s : short key word
r. reptext_ddic : heading(ddic)
s. ddictxt(1) : (S)hort (M)iddle (L)ong
t. datatype : datatype
SLIS_T_EVENT :
Internal table for storing all the possible events of the ALV. This can be populated by the function module Reuse_alv_events_get
The columns are :
name : name of the event
form : name of the routine
SYNTAXES FOR THE ROUTINES
I_CALLBACK_PF_STATUS_SET
Syntax :
FORM set_pf_status USING rt_extab TYPE slis_t_extab
The table RT_EXTAB contains the function codes which are hidden in the standard interface.
I_CALLBACK_USER_COMMAND
Syntax :
FORM user_command USING r_ucomm LIKE sy-ucomm
rs_selfield TYPE slis_selfield.
The parameter r_ucomm contains the function code.
The structure rs_selfield has the details about the current cursor position.
The common features of report are column alignment, sorting, filtering, subtotals, totals etc. To implement these, a lot of coding and logic is to be put. To avoid that we can use a concept called ABAP List Viewer (ALV).
Using ALV, we can have three types of reports:
1. Simple Report
2. Block Report
3. Hierarchical Sequential Report
There are some function modules which will enable to produce the above reports without much effort.
All the definitions of internal tables, structures
and constants are declared in a type-pool called SLIS.
Simple Report
The important function modules are:
•Reuse_alv_list_display
•Reuse_alv_fieldcatalog_merge
•Reuse_alv_events_get
•Reuse_alv_commentary_write
•Reuse_alv_grid_display
A. REUSE_ALV_LIST_DISPLAY: This is the function module which prints the data.
The important parameters are:
1. Export:
a. I_callback_program : report id
b. I_callback_pf_status_set : routine where a user can set his own pf status or change the
functionality of the existing pf -status.
c. I_callback_user_command : routine where the function codes are handled.
d. I_structure name : name of the dictionary table
e. Is_Layout : structure to set the layout of the report
f. It_fieldcat : internal table with the list of all fields and their attributes which are to
be printed (this table can be populated automatically by the function
module REUSE_ALV_FIELDCATALOG_MERGE)
g. It_events : internal table with a list of all possible events of ALVand their
corresponding routine names.
2. Tables:
a. t_outtab : internal table with the data to be output
B. REUSE_ALV_FIELDCATALOG_MERGE:
This function module is used to populate a fieldcatalog which is essential to display the data in ALV. If the output data is from a single dictionary table and all the columns are selected, then we need not exclusively create the field catalog. Its enough to mention the table name as a parameter(I_structure_name) in the REUSE_ALV_LIST_DISPLAY. But in other cases we need to create it.
The important parameters are:
1. Export:
a. I_program_name : report id
b. I_internal_tabname : the internal output table
c. I_inclname : include or the report name where all the dynamic forms are handled.
2. Changing
ct_fieldcat : an internal table with the type SLIS_T_FIELDCAT_ALV which is declared in
the type pool SLIS.
C . REUSE_ALV_EVENTS_GET: Returns table of possible events for a a list type
1. Import:
Et_Events : The event table is returned with all possible CALLBACK events for the
specified list type (column ‘NAME’). For events to be processed by the
callback, their ‘FORM’ field must be filled. If the field is initialized, the event
is ignored. The entry can be read from the event table, the field ‘FORM’ filled
and the entry modified using constants from the type pool SLIS.
2. Export:
I_list_type:
0 = simple list
1 = hierarchical-sequential list
2 = simple block list
3 = hierarchical-sequential block list
D. REUSE_ALV_COMMENTARY_WRITE : This is used in the Top-of-page event to print the headings and other comments for the list.
1. It_list_commentary : Internal table with the headings of the type slis_t_listheader.
This internal table has three fields:
Typ : ‘H’ - header, ‘S’ - selection, ‘A’ - action
Key : only when typ is ‘S’.
Info : the text to be printed
E. REUSE_ALV_GRID_DISPLAY: A new function in 4.6 version, to display the results in grid rather than as a list.
Parameters : same as reuse_alv_list_display
HIERARCHICAL REPORTS
A. REUSE_ALV_HIERSEQ_LIST_DISPLAY
1. Export:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
d. IS_LAYOUT
e. IT_FIELDCAT
f. IT_EVENTS
g. I_TABNAME_HEADER : Name of the internal table in the program containing the output data of the
highest hierarchy level.
h. I_TABNAME_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
i. IS_KEYINFO : This structure contains the header and item table field names which link the two tables
(shared key).
2. Tables
a. T_OUTTAB_HEADER : Header table with data to be output
b. T_OUTTAB_ITEM : Name of the internal table in the program containing the output data of the
lowest hierarchy level.
BLOCK REPORT
This is used to display multiple lists continuously.
The important functions used in this report are:
A. REUSE_ALV_BLOCK_LIST_INIT
B. REUSE_ALV_BLOCK_LIST_APPEND
C. REUSE_ALV_BLOCK_LIST_DISPLAY
D. REUSE_ALV_BLOCK_HS_LIST_APPEND
A. REUSE_ALV_BLOCK_LIST_INIT
Parameters:
a. I_CALLBACK_PROGRAM
b. I_CALLBACK_PF_STATUS_SET
c. I_CALLBACK_USER_COMMAND
This function module is used to set the default GUI status etc.
B. REUSE_ALV_BLOCK_LIST_APPEND
Export :
a. IS_LAYOUT : layout settings for block
b. IT_FIELDCAT : field catalog
c. I_TABNAME : Internal table name of the output data
d. IT_EVENTS : internal table name with all possible events
Tables :
a. T_OUTTAB : internal table with output data.
This function module adds the data to the block.
INTERNAL TABLES IN SLIS
Slis_t_fieldcat_alv :
This internal table contains the field attributes. This internal table can be populated automatically by using ‘REUSE_ALV_FIELDCATALOG_MERGE’.
Important Attributes:
a. col_pos : position of the column
b. fieldname : internal fieldname
c. tabname : internal table name
d. ref_fieldname : fieldname (dictionary)
e. ref_tabname : table (dictionary)
f. key(1) : column with key-color
g. icon(1) : icon
h. hotspot(1) : hotspot
i. Symbol(1) : symbol
j. Checkbox(1) : checkbox
k. just(1) : (R)ight (L)eft (C)ent
l. do_sum(1) : sum up
m. no_out(1) : (O)blig. (X)no out
n. outputlen : output length
o. seltext-l : long key word
p. seltext_m : middle key word
q. seltext_s : short key word
r. reptext_ddic : heading(ddic)
s. ddictxt(1) : (S)hort (M)iddle (L)ong
t. datatype : datatype
SLIS_T_EVENT :
Internal table for storing all the possible events of the ALV. This can be populated by the function module Reuse_alv_events_get
The columns are :
name : name of the event
form : name of the routine
SYNTAXES FOR THE ROUTINES
I_CALLBACK_PF_STATUS_SET
Syntax :
FORM set_pf_status USING rt_extab TYPE slis_t_extab
The table RT_EXTAB contains the function codes which are hidden in the standard interface.
I_CALLBACK_USER_COMMAND
Syntax :
FORM user_command USING r_ucomm LIKE sy-ucomm
rs_selfield TYPE slis_selfield.
The parameter r_ucomm contains the function code.
The structure rs_selfield has the details about the current cursor position.
Subscribe to:
Posts (Atom)
-
Category : ABAP Programming Error Runtime Errors: READ_REPORT_LINE_TOO_LONG Except.: CX_SY_READ_SRC_LINE_TOO_LONG Detail explanati... -
Function module that will take any internal table as input, convert in to XLS format and send out emails with the attachment. Add the... -
Data Class The data class determines the physical area of the database (tablespace) in which the table is created. You set the data...