Rollback handle
i have problem with Rollback action in my UIX application. When i create new page and fill all my fields i go to correct page. When i submit cancel action with rollback i go to back page,i have page with fault data
why?
Sorry, but what was the question ?
Frank
Similar Messages
-
Commit/Rollback in Stored Procedures
I'm just confused about how this setup works. I understand that ODP.NET is in autocommit mode by default, and any INSERT, UPDATE, or DELETE commands are committed automatically. If they fail for any reason, obviously the row(s) are not modified.
But how about sprocs? Do they autocommit as well? If so how are rollbacks handled? Do I need to explicitly create a transaction and commit/rollback? Is it best practice to commit/rollback in the .NET transaction or in the sproc itself?
As you can see, I'm just really looking for info on how these two interact. Any info you can provide will be extremely helpful.
Thanks!Hello,
When ODP.NET is operating in auto-commit mode (the default as you note) this applies to PL/SQL calls as well.
I am of the opinion that the client should be in charge of a transaction and I do not commit/rollback inside PL/SQL code (unless of course I am writing PL/SQL that is the client of other PL/SQL code).
Here's a bit from Tom Kyte on the subject:
http://tkyte.blogspot.com/2007/03/dreaded-others-then-null-strikes-again.html
Just search for the text "Who control the commit?" on that page.
Regards,
Mark -
How to select the data efficiently from the table
hi every one,
i need some help in selecting data from FAGLFLEXA table.i have to select many amounts from different group of G/L accounts
(groups are predefined here which contains a set of g/L account no.).
if i select every time for each group then it will be a performance issue, in order to avoid it what should i do, can any one suggest me a method or a smaple query so that i can perform the task efficiently.Hi ,
1.select and keep the data in internal table
2.avoid select inside loop ..endloop.
3.try to use for all entries
check the below details
Hi Praveen,
Performance Notes
1.Keep the Result Set Small
You should aim to keep the result set small. This reduces both the amount of memory used in the database system and the network load when transferring data to the application server. To reduce the size of your result sets, use the WHERE and HAVING clauses.
Using the WHERE Clause
Whenever you access a database table, you should use a WHERE clause in the corresponding Open SQL statement. Even if a program containing a SELECT statement with no WHERE clause performs well in tests, it may slow down rapidly in your production system, where the data volume increases daily. You should only dispense with the WHERE clause in exceptional cases where you really need the entire contents of the database table every time the statement is executed.
When you use the WHERE clause, the database system optimizes the access and only transfers the required data. You should never transfer unwanted data to the application server and then filter it using ABAP statements.
Using the HAVING Clause
After selecting the required lines in the WHERE clause, the system then processes the GROUP BY clause, if one exists, and summarizes the database lines selected. The HAVING clause allows you to restrict the grouped lines, and in particular, the aggregate expressions, by applying further conditions.
Effect
If you use the WHERE and HAVING clauses correctly:
There are no more physical I/Os in the database than necessary
No unwanted data is stored in the database cache (it could otherwise displace data that is actually required)
The CPU usage of the database host is minimize
The network load is reduced, since only the data that is required by the application is transferred to the application server.
Minimize the Amount of Data Transferred
Data is transferred between the database system and the application server in blocks. Each block is up to 32 KB in size (the precise size depends on your network communication hardware). Administration information is transported in the blocks as well as the data.
To minimize the network load, you should transfer as few blocks as possible. Open SQL allows you to do this as follows:
Restrict the Number of Lines
If you only want to read a certain number of lines in a SELECT statement, use the UP TO <n> ROWS addition in the FROM clause. This tells the database system only to transfer <n> lines back to the application server. This is more efficient than transferring more lines than necessary back to the application server and then discarding them in your ABAP program.
If you expect your WHERE clause to return a large number of duplicate entries, you can use the DISTINCT addition in the SELECT clause.
Restrict the Number of Columns
You should only read the columns from a database table that you actually need in the program. To do this, list the columns in the SELECT clause. Note here that the INTO CORRESPONDING FIELDS addition in the INTO clause is only efficient with large volumes of data, otherwise the runtime required to compare the names is too great. For small amounts of data, use a list of variables in the INTO clause.
Do not use * to select all columns unless you really need them. However, if you list individual columns, you may have to adjust the program if the structure of the database table is changed in the ABAP Dictionary. If you specify the database table dynamically, you must always read all of its columns.
Use Aggregate Functions
If you only want to use data for calculations, it is often more efficient to use the aggregate functions of the SELECT clause than to read the individual entries from the database and perform the calculations in the ABAP program.
Aggregate functions allow you to find out the number of values and find the sum, average, minimum, and maximum values.
Following an aggregate expression, only its result is transferred from the database.
Data Transfer when Changing Table Lines
When you use the UPDATE statement to change lines in the table, you should use the WHERE clause to specify the relevant lines, and then SET statements to change only the required columns.
When you use a work area to overwrite table lines, too much data is often transferred. Furthermore, this method requires an extra SELECT statement to fill the work area. Minimize the Number of Data Transfers
In every Open SQL statement, data is transferred between the application server and the database system. Furthermore, the database system has to construct or reopen the appropriate administration data for each database access. You can therefore minimize the load on the network and the database system by minimizing the number of times you access the database.
Multiple Operations Instead of Single Operations
When you change data using INSERT, UPDATE, and DELETE, use internal tables instead of single entries. If you read data using SELECT, it is worth using multiple operations if you want to process the data more than once, other wise, a simple select loop is more efficient.
Avoid Repeated Access
As a rule you should read a given set of data once only in your program, and using a single access. Avoid accessing the same data more than once (for example, SELECT before an UPDATE).
Avoid Nested SELECT Loops
A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. You should therefore only use nested SELECT loops if the selection in the outer loop contains very few lines.
However, using combinations of data from different database tables is more the rule than the exception in the relational data model. You can use the following techniques to avoid nested SELECT statements:
ABAP Dictionary Views
You can define joins between database tables statically and systemwide as views in the ABAP Dictionary. ABAP Dictionary views can be used by all ABAP programs. One of their advantages is that fields that are common to both tables (join fields) are only transferred once from the database to the application server.
Views in the ABAP Dictionary are implemented as inner joins. If the inner table contains no lines that correspond to lines in the outer table, no data is transferred. This is not always the desired result. For example, when you read data from a text table, you want to include lines in the selection even if the corresponding text does not exist in the required language. If you want to include all of the data from the outer table, you can program a left outer join in ABAP.
The links between the tables in the view are created and optimized by the database system. Like database tables, you can buffer views on the application server. The same buffering rules apply to views as to tables. In other words, it is most appropriate for views that you use mostly to read data. This reduces the network load and the amount of physical I/O in the database.
Joins in the FROM Clause
You can read data from more than one database table in a single SELECT statement by using inner or left outer joins in the FROM clause.
The disadvantage of using joins is that redundant data is read from the hierarchically-superior table if there is a 1:N relationship between the outer and inner tables. This can considerably increase the amount of data transferred from the database to the application server. Therefore, when you program a join, you should ensure that the SELECT clause contains a list of only the columns that you really need. Furthermore, joins bypass the table buffer and read directly from the database. For this reason, you should use an ABAP Dictionary view instead of a join if you only want to read the data.
The runtime of a join statement is heavily dependent on the database optimizer, especially when it contains more than two database tables. However, joins are nearly always quicker than using nested SELECT statements.
Subqueries in the WHERE and HAVING Clauses
Another way of accessing more than one database table in the same Open SQL statement is to use subqueries in the WHERE or HAVING clause. The data from a subquery is not transferred to the application server. Instead, it is used to evaluate conditions in the database system. This is a simple and effective way of programming complex database operations.
Using Internal Tables
It is also possible to avoid nested SELECT loops by placing the selection from the outer loop in an internal table and then running the inner selection once only using the FOR ALL ENTRIES addition. This technique stems from the time before joins were allowed in the FROM clause. On the other hand, it does prevent redundant data from being transferred from the database.
Using a Cursor to Read Data
A further method is to decouple the INTO clause from the SELECT statement by opening a cursor using OPEN CURSOR and reading data line by line using FETCH NEXT CURSOR. You must open a new cursor for each nested loop. In this case, you must ensure yourself that the correct lines are read from the database tables in the correct order. This usually requires a foreign key relationship between the database tables, and that they are sorted by the foreign key. Minimize the Search Overhead
You minimize the size of the result set by using the WHERE and HAVING clauses. To increase the efficiency of these clauses, you should formulate them to fit with the database table indexes.
Database Indexes
Indexes speed up data selection from the database. They consist of selected fields of a table, of which a copy is then made in sorted order. If you specify the index fields correctly in a condition in the WHERE or HAVING clause, the system only searches part of the index (index range scan).
The primary index is always created automatically in the R/3 System. It consists of the primary key fields of the database table. This means that for each combination of fields in the index, there is a maximum of one line in the table. This kind of index is also known as UNIQUE.
If you cannot use the primary index to determine the result set because, for example, none of the primary index fields occur in the WHERE or HAVING clause, the system searches through the entire table (full table scan). For this case, you can create secondary indexes, which can restrict the number of table entries searched to form the result set.
You specify the fields of secondary indexes using the ABAP Dictionary. You can also determine whether the index is unique or not. However, you should not create secondary indexes to cover all possible combinations of fields.
Only create one if you select data by fields that are not contained in another index, and the performance is very poor. Furthermore, you should only create secondary indexes for database tables from which you mainly read, since indexes have to be updated each time the database table is changed. As a rule, secondary indexes should not contain more than four fields, and you should not have more than five indexes for a single database table.
If a table has more than five indexes, you run the risk of the optimizer choosing the wrong one for a particular operation. For this reason, you should avoid indexes with overlapping contents.
Secondary indexes should contain columns that you use frequently in a selection, and that are as highly selective as possible. The fewer table entries that can be selected by a certain column, the higher that columns selectivity. Place the most selective fields at the beginning of the index. Your secondary index should be so selective that each index entry corresponds to at most five percent of the table entries. If this is not the case, it is not worth creating the index. You should also avoid creating indexes for fields that are not always filled, where their value is initial for most entries in the table.
If all of the columns in the SELECT clause are contained in the index, the system does not have to search the actual table data after reading from the index. If you have a SELECT clause with very few columns, you can improve performance dramatically by including these columns in a secondary index.
Formulating Conditions for Indexes
You should bear in mind the following when formulating conditions for the WHERE and HAVING clauses so that the system can use a database index and does not have to use a full table scan.
Check for Equality and Link Using AND
The database index search is particularly efficient if you check all index fields for equality (= or EQ) and link the expressions using AND.
Use Positive Conditions
The database system only supports queries that describe the result in positive terms, for example, EQ or LIKE. It does not support negative expressions like NE or NOT LIKE.
If possible, avoid using the NOT operator in the WHERE clause, because it is not supported by database indexes; invert the logical expression instead.
Using OR
The optimizer usually stops working when an OR expression occurs in the condition. This means that the columns checked using OR are not included in the index search. An exception to this are OR expressions at the outside of conditions. You should try to reformulate conditions that apply OR expressions to columns relevant to the index, for example, into an IN condition.
Using Part of the Index
If you construct an index from several columns, the system can still use it even if you only specify a few of the columns in a condition. However, in this case, the sequence of the columns in the index is important. A column can only be used in the index search if all of the columns before it in the index definition have also been specified in the condition.
Checking for Null Values
The IS NULL condition can cause problems with indexes. Some database systems do not store null values in the index structure. Consequently, this field cannot be used in the index.
Avoid Complex Conditions
Avoid complex conditions, since the statements have to be broken down into their individual components by the database system.
Reduce the Database Load
Unlike application servers and presentation servers, there is only one database server in your system. You should therefore aim to reduce the database load as much as possible. You can use the following methods:
Buffer Tables on the Application Server
You can considerably reduce the time required to access data by buffering it in the application server table buffer. Reading a single entry from table T001 can take between 8 and 600 milliseconds, while reading it from the table buffer takes 0.2 - 1 milliseconds.
Whether a table can be buffered or not depends its technical attributes in the ABAP Dictionary. There are three buffering types:
Resident buffering (100%) The first time the table is accessed, its entire contents are loaded in the table buffer.
Generic buffering In this case, you need to specify a generic key (some of the key fields) in the technical settings of the table in the ABAP Dictionary. The table contents are then divided into generic areas. When you access data with one of the generic keys, the whole generic area is loaded into the table buffer. Client-specific tables are often buffered generically by client.
Partial buffering (single entry) Only single entries are read from the database and stored in the table buffer.
When you read from buffered tables, the following happens:
1. An ABAP program requests data from a buffered table.
2. The ABAP processor interprets the Open SQL statement. If the table is defined as a buffered table in the ABAP Dictionary, the ABAP processor checks in the local buffer on the application server to see if the table (or part of it) has already been buffered.
3. If the table has not yet been buffered, the request is passed on to the database. If the data exists in the buffer, it is sent to the program.
4. The database server passes the data to the application server, which places it in the table buffer.
5. The data is passed to the program.
When you change a buffered table, the following happens:
1. The database table is changed and the buffer on the application server is updated. The database interface logs the update statement in the table DDLOG. If the system has more than one application server, the buffer on the other servers is not updated at once.
2. All application servers periodically read the contents of table DDLOG, and delete the corresponding contents from their buffers where necessary. The granularity depends on the buffering type. The table buffers in a distributed system are generally synchronized every 60 seconds (parameter: rsdisp/bufreftime).
3. Within this period, users on non-synchronized application servers will read old data. The data is not recognized as obsolete until the next buffer synchronization. The next time it is accessed, it is re-read from the database.
You should buffer the following types of tables:
Tables that are read very frequently
Tables that are changed very infrequently
Relatively small tables (few lines, few columns, or short columns)
Tables where delayed update is acceptable.
Once you have buffered a table, take care not to use any Open SQL statements that bypass the buffer.
The SELECT statement bypasses the buffer when you use any of the following:
The BYPASSING BUFFER addition in the FROM clause
The DISTINCT addition in the SELECT clause
Aggregate expressions in the SELECT clause
Joins in the FROM clause
The IS NULL condition in the WHERE clause
Subqueries in the WHERE clause
The ORDER BY clause
The GROUP BY clause
The FOR UPDATE addition
Furthermore, all Native SQL statements bypass the buffer.
Avoid Reading Data Repeatedly
If you avoid reading the same data repeatedly, you both reduce the number of database accesses and reduce the load on the database. Furthermore, a "dirty read" may occur with database tables other than Oracle. This means that the second time you read data from a database table, it may be different from the data read the first time. To ensure that the data in your program is consistent, you should read it once only and then store it in an internal table.
Sort Data in Your ABAP Programs
The ORDER BY clause in the SELECT statement is not necessarily optimized by the database system or executed with the correct index. This can result in increased runtime costs. You should only use ORDER BY if the database sort uses the same index with which the table is read. To find out which index the system uses, use SQL Trace in the ABAP Workbench Performance Trace. If the indexes are not the same, it is more efficient to read the data into an internal table or extract and sort it in the ABAP program using the SORT statement.
Use Logical Databases
SAP supplies logical databases for all applications. A logical database is an ABAP program that decouples Open SQL statements from application programs. They are optimized for the best possible database performance. However, it is important that you use the right logical database. The hierarchy of the data you want to read must reflect the structure of the logical database, otherwise, they can have a negative effect on performance. For example, if you want to read data from a table right at the bottom of the hierarchy of the logical database, it has to read at least the key fields of all tables above it in the hierarchy. In this case, it is more efficient to use a SELECT statement.
Work Processes
Work processes execute the individual dialog steps in R/3 applications. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in the R/3 System.
Structure of a Work Process
Work processes execute the dialog steps of application programs. They are components of an application server. The following diagram shows the components of a work process:
Each work process contains two software processors and a database interface.
Screen Processor
In R/3 application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic. The screen flow logic controls a large part of the user interaction. The R/3 Basis system contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.
ABAP Processor
The actual processing logic of an application program is written in ABAP - SAPs own programming language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.
Database Interface
The database interface provides the following services:
Establishing and terminating connections between the work process and the database.
Access to database tables
Access to R/3 Repository objects (ABAP programs, screens and so on)
Access to catalog information (ABAP Dictionary)
Controlling transactions (commit and rollback handling)
Table buffer administration on the application server.
The following diagram shows the individual components of the database interface:
The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.
Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that the R/3 installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in the R/3 System by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.
Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an application server. Where an R/3 System is distributed across more than one application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change.
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. Programs that use Native SQL are specific to the database system for which they were written. R/3 applications contain as little Native SQL as possible. In fact, it is only used in a few Basis components (for example, to create or change table definitions in the ABAP Dictionary).
The database-dependent layer in the diagram serves to hide the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install the Basis system. Thanks to the standardization of SQL, the differences in the syntax of statements are very slight. However, the semantics and behavior of the statements have not been fully standardized, and the differences in these areas can be greater. When you use Native SQL, the function of the database-dependent layer is minimal.
Types of Work Process
Although all work processes contain the components described above, they can still be divided into different types. The type of a work process determines the kind of task for which it is responsible in the application server. It does not specify a particular set of technical attributes. The individual tasks are distributed to the work processes by the dispatcher.
Before you start your R/3 System, you determine how many work processes it will have, and what their types will be. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your application servers.
The following diagram shows again the structure of an application server, but this time, includes the various possible work process types:
The various work processes are described briefly below. Other parts of this documentation describe the individual components of the application server and the R/3 System in more detail.
Dialog Work Process
Dialog work processes deal with requests from an active user to execute dialog steps.
Update Work Process
Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.
Background Work Process
Background work processes process programs that can be executed without user interaction (background jobs).
Enqueue Work Process
The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.
Spool Work Process
The spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain several spool work process.
The services offered by an application server are determined by the types of its work processes. One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.
You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.
ABAP Application Server
R/3 programs run on application servers. They are an important component of the R/3 System. The following sections describe application servers in more detail.
Structure of an ABAP Application Server
The application layer of an R/3 System is made up of the application servers and the message server. Application programs in an R/3 System are run on application servers. The application servers communicate with the presentation components, the database, and also with each other, using the message server.
The following diagram shows the structure of an application server:
The individual components are:
Work Processes
An application server contains work processes, which are components that can run an application. Work processes are components that are able to execute an application (that is, one dialog step each). Each work process is linked to a memory area containing the context of the application being run. The context contains the current data for the application program. This needs to be available in each dialog step. Further information about the different types of work process is contained later on in this documentation.
Dispatcher
Each application server contains a dispatcher. The dispatcher is the link between the work processes and the users logged onto the application server. Its task is to receive requests for dialog steps from the SAP GUI and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.
Gateway
Each application server contains a gateway. This is the interface for the R/3 communication protocols (RFC, CPI/C). It can communicate with other application servers in the same R/3 System, with other R/3 Systems, with R/2 Systems, or with non-SAP systems.
The application server structure as described here aids the performance and scalability of the entire R/3 System. The fixed number of work processes and dispatching of dialog steps leads to optimal memory use, since it means that certain components and the memory areas of a work process are application-independent and reusable. The fact that the individual work processes work independently makes them suitable for a multi-processor architecture. The methods used in the dispatcher to distribute tasks to work processes are discussed more closely in the section Dispatching Dialog Steps.
Shared Memory
All of the work processes on an application server use a common main memory area called shared memory to save contexts or to buffer constant data locally.
The resources that all work processes use (such as programs and table contents) are contained in shared memory. Memory management in the R/3 System ensures that the work processes always address the correct context, that is the data relevant to the current state of the program that is running. A mapping process projects the required context for a dialog step from shared memory into the address of the relevant work process. This reduces the actual copying to a minimum.
Local buffering of data in the shared memory of the application server reduces the number of database reads required. This reduces access times for application programs considerably. For optimal use of the buffer, you can concentrate individual applications (financial accounting, logistics, human resources) into separate application server groups.
Database Connection
When you start up an R/3 System, each application server registers its work processes with the database layer, and receives a single dedicated channel for each. While the system is running, each work process is a user (client) of the database system (server). You cannot change the work process registration while the system is running. Neither can you reassign a database channel from one work process to another. For this reason, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. This has important consequences for the programming model explained below.
Dispatching Dialog Steps
The number of users logged onto an application server is often many times greater than the number of available work processes. Furthermore, it is not restricted by the R/3 system architecture. Furthermore, each user can run several applications at once. The dispatcher has the important task of distributing all dialog steps among the work processes on the application server.
The following diagram is an example of how this might happen:
1. The dispatcher receives the request to execute a dialog step from user 1 and directs it to work process 1, which happens to be free. The work process addresses the context of the application program (in shared memory) and executes the dialog step. It then becomes free again.
2. The dispatcher receives the request to execute a dialog step from user 2 and directs it to work process 1, which is now free again. The work process executes the dialog step as in step 1.
3. While work process 1 is still working, the dispatcher receives a further request from user 1 and directs it to work process 2, which is free.
4. After work processes 1 and 2 have finished processing their dialog steps, the dispatcher receives another request from user 1 and directs it to work process 1, which is free again.
5. While work process 1 is still working, the dispatcher receives a further request from user 2 and directs it to work process 2, which is free.
From this example, we can see that:
A dialog step from a program is assigned to a single work process for execution.
The individual dialog steps of a program can be executed on different work processes, and the program context must be addressed for each new work process.
A work process can execute dialog steps of different programs from different users.
The example does not show that the dispatcher tries to distribute the requests to the work processes such that the same work process is used as often as possible for the successive dialog steps in an application. This is useful, since it saves the program context having to be addressed each time a dialog step is executed.
Dispatching and the Programming Model
The separation of application and presentation layer made it necessary to split up application programs into dialog steps. This, and the fact that dialog steps are dispatched to individual work processes, has had important consequences for the programming model.
As mentioned above, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. The contents of the database must be consistent at its beginning and end. The beginning and end of a database LUW are defined by a commit command to the database system (database commit). During a database LUW, that is, between two database commits, the database system itself ensures consistency within the database. In other words, it takes over tasks such as locking database entries while they are being edited, or restoring the old data (rollback) if a step terminates in an error.
A typical SAP application program extends over several screens and the corresponding dialog steps. The user requests database changes on the individual screens that should lead to the database being consistent once the screens have all been processed. However, the individual dialog steps run on different work processes, and a single work process can process dialog steps from other applications. It is clear that two or more independent applications whose dialog steps happen to be processed on the same work process cannot be allowed to work with the same database LUW.
Consequently, a work process must open a separate database LUW for each dialog step. The work process sends a commit command (database commit) to the database at the end of each dialog step in which it makes database changes. These commit commands are called implicit database commits, since they are not explicitly written into the application program.
These implicit database commits mean that a database LUW can be kept open for a maximum of one dialog step. This leads to a considerable reduction in database load, serialization, and deadlocks, and enables a large number of users to use the same system.
However, the question now arises of how this method (1 dialog step = 1 database LUW) can be reconciled with the demand to make commits and rollbacks dependent on the logical flow of the application program instead of the technical distribution of dialog steps. Database update requests that depend on one another form logical units in the program that extend over more than one dialog step. The database changes associated with these logical units must be executed together and must also be able to be undone together.
The SAP programming model contains a series of bundling techniques that allow you to group database updates together in logical units. The section of an R/3 application program that bundles a set of logically-associated database operations is called an SAP LUW. Unlike a database LUW, a SAP LUW includes all of the dialog steps in a logical unit, including the database update.
Happy Reading...
shibu -
ME21N Update Text in Line Item User Exit
Hi, I have created a new PO text item for use in ME21N that I want to populate from document details held in the material master. After entering a material number what user exit do I need to use to update internal tables for display of the document details before they are saved along with the other PO details. I know the tables where the material document details are held. Thanks.
BADI ME_PROCESS_PO_CUST.
Note that this BADI has a number of methods with parameters defined as "Importing" which makes it look like you cannot change data, but some of these parameters are "TYPE REF TO" objects which themselves have methods such as GET_DATA and SET_DATA that actually allow you to access and change the fields.
Search for previous posts including "ME_PROCESS_PO_CUST" - there is sample code in some of them.
In transaction SE19, if you display the BADI then select menu option goto>sample code>display, you will be able to drill down on the PROCESS_ITEM method to some SAP supplied sample code.
This includes the definitions and method calls to get the item data:
DATA: ls_mepoitem TYPE mepoitem.
ls_mepoitem = im_item->get_data( ).
You then just change relevant fields in structure ls_mepoitem and call the set_data method to pass the data back
call method im_item->set_data exporting im_data = ls_mepoitem.
Take care with what you change - SAP does not validate that you have passed back correct / consistant data.
Not sure if the text field you want will be available - you may need to look at further methods of the BADI or of the parameter objects. If you drill down on the objects that the method parameters are defined as TYPE REF TO you will see the methods that are available - the GET_DATA and SET_DATA ones I have mentioned above are only a small part of the options. If there are none dealing with texts at the Header / Line, then you may need to put your code in at the latest method available (once the PO number is allocated) and call the SAVE_TEXT function module to do your update - not 100% way of doing it because standard code may save in update event and have rollback handling.
To use the BADI you will need to create an implementation of it - there is a menu option in SE18 to do this, or you can use SE19.
Andrew -
Newbie: Simple Reads, Transactions, Pooling and Code Form
I am currently refactoring a set of code (assembly) called by a windows service that provides persistence to an Oracle DB (DataAccessComponent). The motivation for the request to perform this work was to reduce connections to the Oracle DB.
The most salient cause I believe of the excessive connections is the intermingling of ODP and the MS.Net Oracle provider. This has been removed and all code now utilizes ODP.
My problem: The DataAccessComponent undergoing a refactor itself depends (half of the code access methods) heavily on another external assembly that was created to manage all access to the Oracle DB (DataManagment). This DataManagment component Requires a call to its own BeginTransaction() method. This BeginTransaction() behavioral facade then proceeds to create a new OracleConnection then OracleTransaction and adds it to an internal STACK. From what I can tell this stack is and its Transactions are initially independent of an OracleCommand. Then when a Command is executed in this DataManagment component it checks its internal state/stack for an active Transaction and either: joins the currently executing internally-referenced Transaction if it has not been committed or POPs the STACK for an available Transaction. The ostensible reason (assumptions) for this architecture are a) a joined Transaction only utilizes one Connection to the Oracle DB - thereby minimizing connections and b) an attempt to execute two Transactions on a single Connection will (reportedly) cause an exception and c) served as a basis for a home-grown code data access code generation tool.
The side effects (as I see them) of utilizing this external DataManagment assembly (with its Transaction stack) are that even simple ExecuteReader() (database read only) must participate in a Transaction (indeed create one if none exists). Furthermore, in my more familiar MS SQL .Net provider world, the general rule I believe is that the .Net provider takes care of caching the Connection and two separate Transactions that attempt execute a command at roughly the same time (overlap) will not throw an exception. Furthermore, I am not accustomed to wrapping simple database reads in Transactions - seems like overkill to me.
My preferred method of performing reads and writes to Oracle would be to utilize what I know of ADO styled data access in general:
using(OracleConnection conn = new OracleConnection(ConnectionString))
using(OracleCommand cmd = new OracleCommand(SqlStatementString,conn))
cmd.CommandType = CommandType.Text;
cmd.Connection.Open();
using(OracleDataReader rdr = cmd.ExecuteReader(CommandBehavior.CloseConnection))
while(rdr.Read())
//Do something with reader data
rdr.Close();
//Should I call conn.Close();
using (OracleConnection conn = new OracleConnection(ConnectionString))
using (OracleCommand cmd = new OracleCommand(OraclePackageString, conn))
cmd.CommandType = CommandType.StoredProcedure;
//cmd.Parameters.Add(...);
//cmd.Parameters.Add(...);
cmd.Connection.Open();
using(OracleTransaction tran = cmd.Connection.BeginTransaction())
try
cmd.ExecuteNonQuery();
tran.Commit();
catch
tran.Rollback();
//Handle exception
//Should I call conn.Close();
So I have done some research and know that Transactions are scoped to connections. Do that mean that if the above two routines execute simultaneously they will a) create two separate connections? b) throw an exception?
Furthermore, if I call two of the second routines (Transacted) simultaneously with I a) get an exception? b) create two separate connections?
And lastly, if I am calling a bunch of the first type of routine above (non-transacted, read-only) will I a) create a new connection with every call? b) use the same ODP provider cache connection?
Also most of these access routines that do writes, only update a single table and row. If that’s all that is being done and I am not participating in Save Points for rollback do I need a transaction on the writes at all? (Given that I would need to respond to an exception as part of the application logic)
I am not familiar with Oracle connection pooling so I am also not sure if I should be implicitly calling Dispose() on the Connection object(s) above -> which in turn calls Close() or even calling close manually. I read in a post on these boards that if you are running connection pooling you should leave the connection open?
Any help much appreciated... I
Thanks, BradI may not be able to answer all of your questions but I can certainly attempt to answer your questions related to connection pooling. Based on the code samples you posted, I do not see any threading issue with connection or transaction since you are always creating a new connection object and always a new txn.
Once you are done with the connection, you should call conn.Close() so that the underlying session returned to the ODP.NET connection pool as you need not keep connection open to utilize ODP.NET connection pooling. Obviously, in your sample, you are using the "using" clause which will implicitly dispose the connection object hence you do not need to call Close here as Dispose should close the connection. -
Dear All,
We have a Import PO where the currency of that vendor is JPY which is having 4 decimals. The strange thing is in PO we have 2500 qty while we received the first schedule system is allowing to do GRN for any no of qty.
But for second schedule system is not allowing GRN and throwing Dump error at the tme of 105.
For eg:
PO no: 45000023 has 2500 qty but we did grn only for 100 qty then there is no issue it allowed to do GRN
Second time for 100 qty if we try system is throwing dump error
We created new po there also only for one tme system is allowing to do gr other wise it is not allowing. We did debugging but could not able to find.
Please suggest.DEar Sir,
Please find the below dump error. I could not able to attach it as document
Category
ABAP Programming Error
Runtime Errors
MESSAGE_TYPE_X
ABAP Program
SAPMSSY0
Application Component BC-ABA-LA
Date and Time
27.03.2014 10:10:12
Short text
The current application triggered a termination with a short dump.
What happened?
The current application program detected a situation which really
should not occur. Therefore, a termination with a short dump was
triggered on purpose by the key word MESSAGE (type X).
What can you do?
Note down which actions and inputs caused the error.
To process the problem further, contact you SAP system
administrator.
Using Transaction ST22 for ABAP Dump Analysis, you can look
at and manage termination messages, and you can also
keep them for a long time.
Error analysis
Short text of error message:
COMMIT WORK during ON COMMIT or ON ROLLBACK
Long text of error message:
Technical information about the message:
Message class....... 00
Number.............. 085
Variable 1.......... " "
Variable 2.......... " "
Variable 3.......... " "
Variable 4.......... " "
How to correct the error
Probably the only way to eliminate the error is to correct the program.
If the error occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:
"MESSAGE_TYPE_X" " "
"SAPMSSY0" or "SAPMSSY0"
"%_BEFORE_COMMIT"
If you cannot solve the problem yourself and want to send an error
notification to SAP, include the following information:
1. The description of the current problem (short dump)
To save the description, choose "System->List->Save->Local File
(Unconverted)".
2. Corresponding system log
Display the system log by calling transaction SM21.
Restrict the time interval to 10 minutes before and five minutes
after the short dump. Then choose "System->List->Save->Local File
(Unconverted)".
3. If the problem occurs in a problem of your own or a modified SAP
program: The source code of the program
In the editor, choose "Utilities->More
Utilities->Upload/Download->Download".
4. Details about the conditions under which the error occurred or which
actions and input led to the error.
System environment
SAP Release..... 731
SAP Basis Level. 0006
Application server... "msqas"
Network address...... "192.168.140.89"
Operating system..... "Linux"
Release.............. "2.6.32-220.el6.x86_6"
Hardware type........ "x86_64"
Character length.... 16 Bits
Pointer length....... 64 Bits
Work process number.. 12
Shortdump setting.... "full"
Database server... "msqas"
Database type..... "ORACLE"
Database name..... "QAS"
Database user ID.. "SAPSR3"
Terminal.......... "C1031"
Char.set.... "C"
SAP kernel....... 720
created (date)... "Aug 15 2011 20:19:20"
create on........ "Linux GNU SLES-11 x86_64 cc4.3.4 use-pr101110"
Database version. "OCI_112, 11.2.0.3.0, V1, default"
Patch level. 100
Patch text.. " "
Database............. "ORACLE 10.1.0.*.*, ORACLE 10.2.0.*.*, ORACLE 11.2.*.*.*"
SAP database version. 720
Operating system..... "Linux 2.6"
Memory consumption
Roll.... 0
EM...... 37708272
Heap.... 0
Page.... 237568
MM Used. 1309640
MM Free. 2877528
User and Transaction
Client.............. 900
User................ "ADMIN"
Language key........ "E"
Transaction......... "MIGO "
Transaction ID...... "5331516F2A4E2866E1000000C0A88C59"
EPP Whole Context ID.... "5CF3FCE6DD4C1EE3ADABD70ED2D199C7"
EPP Connection ID....... 00000000000000000000000000000000
EPP Caller Counter...... 0
Program............. "SAPMSSY0"
Screen.............. "SAPMS380 0100"
Screen Line......... 3
Debugger Active..... "none"
Information on where terminated
Termination occurred in the ABAP program "SAPMSSY0" - in "%_BEFORE_COMMIT".
The main program was "SAPMS380 ".
In the source code you have the termination point in line 196
of the (Include) program "SAPMSSY0".
Source Code Extract
Line
SourceCde
166
rb_orders_wa-i_level = i_level.
167
insert rb_orders_wa into rb_orders index sy-tabix.
168
endif.
169
endif.
170
endform.
"%_order_form_for_rollback
171
172
173
174
* %_COMMIT_PREPARE
175
* Set date and time for aRFC
176
177
form %_commit_prepare using date time.
"#EC *
178
179
%_sys000-arfc-send_time = time.
180
%_sys000-arfc-send_date = date.
181
182
endform.
"%_commit_prepare
183
184
185
* FORM %_BEFORE_COMMIT
186
* called from RSYN commit.rs1
187
188
form %_before_commit.
"#EC *
189
data: l_oncom like sy-oncom.
190
data: txend type c.
191
192
* forbid COMMIT if already in ON ROLLBACK handling
193
* allow COMMIT during ON COMMIT for backward compatibilty
194
call 'GET_SWITCH_TXEND' id 'STATE' field txend.
195
if txend = 'R'.
>>>>>
message x085(00).
197
endif.
198
199
* COMMIT during CALL DIALOG/SUBMIT, POC, Update task
200
* or End Transaction event?
201
check sy-oncom <> 'N' and sy-oncom <> 'P' and
202
sy-oncom <> 'E' and sy-oncom <> 'V'.
203
* change sy-oncom to avoid recursion
204
l_oncom = sy-oncom.
205
sy-oncom = 'E'.
"E = Event Handling
206
207
* no escape out off this form other than ENDFORM
208
system-call state_limit set.
209
* Hook for Process Information Infrastructure
210
call function 'SPI_AGENT_COMMIT'.
211
* Raise event 'Commit Requested' for Object Manager
212
call method cl_os_transaction_end_notifier=>raise_commit_requested.
213
* restore sy-oncom
214
sy-oncom = l_oncom.
215
Contents of system fields
Name
Val.
SY-SUBRC
0
SY-INDEX
0
SY-TABIX
0
SY-DBCNT
0
SY-FDPOS
0
SY-LSIND
0
SY-PAGNO
0
SY-LINNO
1
SY-COLNO
1
SY-PFKEY
SY-UCOMM
SY-TITLE
ABAP Runtime Error
SY-MSGTY
X
SY-MSGID
00
SY-MSGNO
085
SY-MSGV1
SY-MSGV2
SY-MSGV3
SY-MSGV4
SY-MODNO
1
SY-DATUM
20140327
SY-UZEIT
101011
SY-XPROG
SY-XFORM
Active Calls/Events
No. Ty.
Program
Include
Line
Name
4 FORM
SAPMSSY0
SAPMSSY0
196
%_BEFORE_COMMIT
3 FORM
SAPMS380
MS380F10
1287
DELETE_OLD_SNAP_RECORDS
2 FORM
SAPMS380
MS380F10
15
INIT
1 MODULE (PBO) SAPMS380
MS380O10
14
PBO_100_MAIN
Chosen variables
Name
Val.
No.
4
Ty.
FORM
Name
%_BEFORE_COMMIT
DP_J2EE_INACTIVE
0
4
04
TXEND
R
5
2
0
0
5200
%_SYS000-ARFC-DONTSEND
2
0
0
0
2000
%_PRINT
000
0###
2222333222222222222222222222222222222222222222222222222222222222222222222222222222222222223000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2000200020002000300030003000200020002000200020002000200020002000200020002000200020002000200020
SY-REPID
SAPMSSY0
5454555322222222222222222222222222222222
310D339000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
5300410050004D00530053005900300020002000200020002000200020002000200020002000200020002000200020
SY-MSGID
00
33222222222222222222
00000000000000000000
00000000000000000000
00000000000000000000
30003000200020002000200020002000200020002000200020002000200020002000200020002000
%_SYS000
00000000000000
2333333333333332222222222222222222222222
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
2000300030003000300030003000300030003000300030003000300030002000200020002000200020002000200020
RST_VB_DISPATCHING_INFO
0
A
0A
SPACE
2
0
0
0
2000
SY-MSGNO
085
333
085
000
000
300038003500
%_TIME_CONFIRMED
001000
333333
001000
000000
000000
300030003100300030003000
SY-MSGV1
22222222222222222222222222222222222222222222222222
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SY-MSGV2
22222222222222222222222222222222222222222222222222
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SY-MSGV3
22222222222222222222222222222222222222222222222222
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SY-MSGV4
22222222222222222222222222222222222222222222222222
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SY-ONCOM
N
4
E
0
0
4E00
SYST-REPID
SAPMSSY0
5454555322222222222222222222222222222222
310D339000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
5300410050004D00530053005900300020002000200020002000200020002000200020002000200020002000200020
TH_BOOL
0
0
00
%_DUMMY$$
2222
0000
0000
0000
2000200020002000
No.
3
Ty.
FORM
Name
DELETE_OLD_SNAP_RECORDS
DELT-DATUM
00000000
33333333
00000000
00000000
00000000
30003000300030003000300030003000
%_DUMMY$$
2222
0000
0000
0000
2000200020002000
DELT-UZEIT
000000
333333
000000
000000
000000
300030003000300030003000
SY-REPID
SAPMS380
5454533322222222222222222222222222222222
310D338000000000000000000000000000000000
0000000000000000000000000000000000000000
0000000000000000000000000000000000000000
5300410050004D00530033003800300020002000200020002000200020002000200020002000200020002000200020
DELT-AHOST
22222222222222222222222222222222
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
2000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020
SYST-REPID
SAPMS380
5454533322222222222222222222222222222222 -
Hi Experts..
I would like to know how to create a databases in SQL and have access from ABAP.. to Modify, Consult and do the basic operations like insert information, drop and modify in the respective tables.
I'm ussing MiniSap Minigui 6.2 on Windows XP and the BCUSER
Thank you very much for your help
REGARDSHI Araceli,
Database Access using Advanced Business Application Programming (ABAP)
Basics :
Accessing the Database in the R/3 System is performed through the interface provided by the SAP System, which in the SAP System is referred to as the Database Interface. A user can access the database from his/her program through Open SQL and Native SQL depending upon the circumstances.
About SQL
The Structured Query Language (SQL) is a largely standardized language, which is used for accessing relational databases. It can be divided as follows:
Data Manipulation Language (DML)
These statements are for reading and changing data in database tables.
Data Definition Language (DDL)
These statements are for creating and administering database tables.
Data Control Language (DCL)
These statements are used for authorization and consistency checks.
So each database has a programming interface. This programming interface allows the user to access the database tables by using SQL statements. But, these SQL statements in the programming interfaces are not fully standardized. So, you must refer to the documentation of that system for a list of the SQL statements available and also their correct syntax in order to access a specific database system.
Interface thru data base
Each work process on an application server must have a database interface if you want to make the R/3 system independent of the database system, and also to use it correctly despite the differences in the SQL syntax between various databases. By means of this interface only, the R/3 system can communicate with the database. All of the database requests from the R/3 system are converted into the correct Standard SQL statements for the database system by the database interface. In order to perform this function, it has to use a database-specific component, which shields the differences between database systems from the rest of the database interface. You have to choose the appropriate layer when installing the R/3 system. A user can access a database from a program through Open SQL and Native SQL.
Open SQL
Open SQL are statements that make up a subset of Standard SQL which is fully integrated in ABAP. Open SQL consists of Data Manipulation Language (DML) which is a part of Standard SQL.
One of the ways to access the database from a program is Open SQL. These Open SQL statements are nothing but a subset of Standard SQL, which is fully integrated in ABAP. Irrespective of which database system the R/3 installation is using, they allow you to access data. When I said that, Open SQL consists of the Data Manipulation Language (DML). I meant that it allows you to read (i.e. to SELECT) and change (For example to INSERT, UPDATE, DELETE) data.
Moreover, Open SQL also goes beyond Standard SQL. This is to provide statements that can simplify or speed up database access in conjunction with other ABAP constructions. Apart from that, it also gives you the freedom to buffer certain tables on the application server, thereby enabling you to save excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. As far as buffer storage is concerned, they may be stored in two parts: the working memory of the current work process, and the shared memory for all work processes on an application server. The data in the various buffers is synchronized at set intervals by buffer management where an R/3 system is distributed across more than one application server. It should be noted that data in the buffer is not always up to date when you are buffering the database. That is why you should only use the buffer for data which does not change often. You can specify whether a table can be buffered in its definition in the ABAP Dictionary.
Open SQL consists of a set of ABAP statements. These statements perform operations on the central database in the R/3 system. The results of the operations and any error messages which come out of it are independent of the current database system. Thus, uniform syntax and semantics for all of the database systems supported by SAP is provided by Open SQL. Regardless of the current database system, the ABAP programs, which use Open SQL statements only, will work in any R/3 system. Moreover, Open SQL statements work only with database tables that have been created in the ABAP Dictionary.
You have the freedom to combine columns belonging to different database tables to a database view (or view for short) in the ABAP Dictionary. Views are also handled in exactly the same way as database tables in Open SQL statements.
Some Open SQL keywords are as follows:
SELECT - It reads data from database tables.
INSERT - It adds rows to database tables.
UPDATE - It changes the contents of rows of database tables.
MODIFY - It inserts rows into database tables or changes the content of existing rows.
DELETE - It deletes rows from database tables.
OPEN CURSOR, FETCH, CLOSE CURSOR - It reads rows of database tables using the cursor.
Return Codes
The following two system fields are filled with return codes by all Open SQL statements:
SY-SUBRC: The system field SY -SUBRC contains the value 0 after every Open SQL statement if the operation was successful. When a value is other than 0, then it is unsuccessful.
SY-DBCNT: The system field SY-DBCNT contains the number of database lines processed after an open SQL statement.
Native SQL
The other possible way to access the database from a program is Native SQL. It is only loosely integrated into ABAP. It allows access to all of the functions contained in the programming interface of the respective database system. Native SQL statements are not checked and converted as compared to Open SQL statements. Unlike Open SQL, these are sent directly to the database system. The function of the database-dependent layer remains minimal when you use Native SQL. The Programs which use Native SQL are written specifically for a database system. You should avoid using Native SQL wherever possible when writing R/3 applications. However, you can use it in some parts of the R/3 Basis System, for instance, for creating or changing table definitions in the ABAP Dictionary.
Regardless of the database platform that your R/3 system is using, Open SQL allows you to access database tables, which are declared in the ABAP Dictionary. Native SQL allows you to use database specific SQL statements in an ABAP program. This means that you can use database tables that are not administered by the ABAP Dictionary. Aside from that, you can also integrate data that is not part of the R/3 system.
As a rule, an ABAP program that contains database-specific SQL statements will not run under different database systems. You have to use Open SQL statements only, if your program is used on more than one database platform.
You must proceed with the EXEC SQL statement, and follow the ENDEXEC statement to use a: Native SQL statement. For example
Listing 1
EXEC SQL [PERFORMING
ENDEXEC.There is no period after Native SQL statements. Also, using quotation marks (") or an asterisk (*) at the beginning of a native SQL statement's line does not introduce a comment as it would in normal ABAP syntax. You need to know if the table and field names are case-sensitive in your chosen database.
The data is transported between the database table and the ABAP program using host variables in Native SQL statements. These are preceded in a Native SQL statement by a colon ( and are declared in the ABAP program. The elementary structures can be used as host variables. The structures of an INTO clause are treated exceptionally, as though all of their fields are listed individually. If the selection in a Native SQL SELECT statement is a table, then you can pass it to ABAP line by line using the PERFORMING addition. For each line read, the program calls a subroutine
. Further, you can process the data within the subroutine.
After the ENDEXEC statement, SY-DBCNT contains the number of lines processed as it does in Open SQL. In almost all cases, SY-SUBRC contains the value a after the ENDEXEC statement. Cursor operations form an exception: after FETCH, SY-SUBRC is 4 if no more records could be read. This is also applied when you read a result set using EXEC SQL PERFORMING.
Native SQL Scope
Native SQL is very important as it allows you to execute nearly all available statements through the SQL programming interface (usually known as SQL Call Interface or similar) for directly executing SQL program code (using EXEC IMMEDIATE or a similar command). The statements that are not supported are listed in the following section:
· Native SQL and the Database Interface,
· Native SQL and Transactions
· Native SQL and the Database Interface
Native SQL statements bypass the R/3 database interface. With the database buffer on the application server, there is no table logging, and no synchronization. Therefore, you should use Open SQL to change database tables declare in the ABAP dictionary wherever possible. Since the columns contain extra database specific length information for the column tables declared in the ABAP dictionary, containing long columns with the type LCHAR or LRAW should only be addressed using Open SQL. Native SQL may not produce the correct result, as it does not take this information into account. Native SQL does not support automatic client handling. Instead, you must treat a client field like any other field
Native SQL and Transactions
One should not use any transaction control statement such as COMMIT, ROLLBACK WORK, or any statements that set transaction parameters using Native SQL to ensure that transaction in the R/3 System are consistent.
ABAP Dictionary
The ABAP Dictionary is nothing but a part of the ABAP Workbench. It allows you to create and administer database tables. There are no statements from the DDL part of Standard SQL in Open SQL. It should be noted that normal application programs should not create or change their own database tables.
To create and change database tables, the ABAP Dictionary has to use the DDL part of Open SQL. Besides this, it also administers the ABAP Dictionary in the database. In addition, the ABAP Dictionary contains meta-descriptions of all database tables in the R/3 system. Here, only database tables appears in the Dictionary, which you have created using the ABAP Dictionary. Open SQL statements can only access tables, which exists in the ABAP Dictionary.
Authorization and Consistency Checks
With regard to authorization and consistency checks, the DCL part of Standard SQL is not used in R/3 programs. Whereas, the work processes which are within the R/3 system are logged into the database system as users with full rights. By using the R/3 authorization concept, the authorizations of programs or users to read or change database tables is administered within the R/3 system. In addition, transactions must equally ensure their own data consistency using the R/3 locking concept.
The R/3 lock concept allows you to monitor your system with regards to lock logics. The R/3 lock concept works closely together with the R/3 updates.
As an example, say that a travel agent wants to book a flight for a customer who wants to fly to a particular city with a certain airline on a certain day. If there are still available seats on the flight, then the booking will be possible, otherwise it will lead to overbooking. Hence, the database entry corresponding to the flight must be locked against access from other transactions to avoid the possibility of overbooking. This is because two agents might both be doing this same thing at the same time, and we need to make sure that we don't overbook.
Lock Mechanisms
When the database system receives change statements (INSERT, UPDATE, MODIFY, DELETE) from a program, it automatically sets database locks. Database locks are locks on the database entries affected by statements to prevent problems. Since the lock mechanism uses a, lock flag in the entry, you can only set a lock for an existing database entry. After each database commit, these flags are automatically deleted. This means that database locks can never be set for longer than a single database LUW, a single dialog step in an R/3 application program.
Therefore, physical locks in the database system are insufficient for the requirements of an R/3 transaction. Locks in the R/3 system must remain set for the duration of a whole SAP LUW, that is, over several dialog steps. They must also be capable of being handled by different work processes and application servers. As a result, each lock must apply on all servers in that R/3 system.
Database Accesses of the NetWeaver AS ABAP
The NetWeaver AS ABAP stores long-term data in a central relational database table. In a relational database model, the real world is represented by tables. A table is a two-dimensional matrix, consisting of lines and columns (fields). The smallest possible combination of fields that can uniquely identify each line of the table is called the key. Each table must have at least one key, and each table has one key that is defined as its primary key. Relationships between tables are represented by foreign keys.
Standard SQL
SQL (Structured Query Language) is a largely standardized language for accessing relational databases. It can be divided into three areas:
· Data Manipulation Language (DML)
Statements for reading and changing data in database tables.
· Data Definition Language (DDL)
Statements for creating and administering database tables.
· Data Control Language (DCL)
Statements for authorization and consistency checks.
Each database has a programming interface that allows you to access the database tables using SQL statements. The SQL statements in these programming interfaces are not fully standardized. To access a specific database system, you must refer to the documentation of that system for a list of the SQL statements available and their correct syntax.
The Database Interface
To avoid incompatible situations between different database tables and to make the NetWeaver AS ABAP system independent of the database system in use, each work process on an ABAP application server contains a database interface. The NW AS communicates with the database solely through the database interface. The database interface converts all of the database requests from the NW AS into the correct Standard SQL statements for the database system in use. To do this, it uses a database-specific component that shields the differences between database systems from the rest of the database interface. You choose the this component when you install NetWeaver AS ABAP in accordance with the database in use.
ABAP programs have two options for accessing the database interface: Open SQL and Native SQL.
Open SQL
Open SQL statements are a fully integrated subset of Standard SQL within ABAP. They enable the ABAP programs to access data irrespective of the database system installed. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data.
Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an application server. In SAP systems that are distributed across more than one application server, the data in the various buffers is synchronized at set intervals by buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change. You specify whether a table can be buffered in its definition in the ABAP Dictionary.
Native SQL
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. When you use Native SQL, the function of the database-dependent layer is minimal. Programs that use Native SQL are specific to the database system for which they were written. When developing generally valid ABAP applications, you should as far as possible avoid using Native SQL. In some components of the SAP System, Native SQL is used for example, in the ABAP Dictionary for creating or changing tables.
The ABAP Dictionary
The ABAP Dictionary, part of the ABAP Workbench, allows you to create and administer database tables. Open SQL contains no statements from the DDL part of Standard SQL. Normal application programs should not create or change their own database tables.
The ABAP Dictionary uses the DDL part of Open SQL to create and change database tables. It also administers the ABAP Dictionary in the database. The ABAP Dictionary contains meta descriptions of all database tables in the NetWeaver AS ABAP system. Only database tables that you create using the ABAP Dictionary appear in the Dictionary. Open SQL statements can only access tables that exist in the ABAP Dictionary.
Authorization and Consistency Checks
The DCL part of Standard SQL is not important in ABAP programs. The work processes within the ABAP application server are logged on to the database system as users with full authorization. The authorizations of programs or program users to read or change database tables is managed by the authorization concept. Equally, transactions must ensure their own data consistency in the database using the SAP locking concept. For more information, refer to the chapter Data Consistency.
Work Processes
Work processes execute the individual dialog steps of ABAP application programs. They are components of ABAP application servers. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in NetWeaver AS ABAP.
Structure of a Work Process
The following diagram shows the components of a work process:
Screen Processor
In ABAP application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic, which controls a large part of the user interaction. NetWeaver AS ABAP contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.
ABAP Processor
The actual processing logic of an application program is written in ABAP - SAPs own programming language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.
Database Interface
The database interface provides the following services:
· Establishing and terminating connections between the work process and the database.
· Access to database tables
· Access to Repository objects (ABAP programs, screens and so on)
· Access to catalog information (ABAP Dictionary)
· Controlling transactions (commit and rollback handling)
· Table buffer administration on the ABAP application server.
The following diagram shows the individual components of the database interface:
The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.
Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that your installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in NetWeaver AS ABAP by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.
Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the ABAP application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an ABAP application server. Where NetWeaver AS ABAP is distributed across more than one ABAP application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change.
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. In Native SQL, you can primarily use database-specific SQL statements. The Native SQL interface sends them as is to the database system where they are executed. You can use the full SQL language scope of the respective database which makes all programs using Native SQL specific for the database system installed. In addition, there is a small set of SAP-specific Native SQL statements which are handled in a special way by the Native SQL interface. ABAP applications contain as little Native SQL as possible. In fact, it is only used in a few components (for example, to create or change table definitions in the ABAP Dictionary).
The database-dependent layer in the diagram serves to hide the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install NetWeaver AS ABAP. Thanks to the standardization of SQL, the differences in the syntax of statements are very slight. However, the semantics and behavior of the statements have not been fully standardized, and the differences in these areas can be greater. When you use Native SQL, the function of the database-dependent layer is minimal.
Types of Work Process
Before you start NetWeaver AS ABAP, you determine how many work processes each ABAP application server will have, and what their types will be. Since all work processes have the same structure (see preceding section), the type of work process does not determine the technical attrributes of the ABAP application server but the type of tasks to be performed on it. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your ABAP application servers.
The following diagram shows again the structure of an ABAP application server, but this time, includes the various possible work process types:
Dialog Work Process
Dialog work processes deal with requests from an active user to execute dialog steps (see also Dialog Programming).
Update Work Process
Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.
Background Work Process
Background work processes process programs that can be executed without user interaction (background jobs).
Enqueue Work Process
The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for NetWeaver AS ABAP and is an important part of the SAP LUW concept. In NW AS, you may only have one lock table. You may therefore also only have one ABAP application server with enqueue work processes. Normally, a single enqueue work process is sufficient to perform the required tasks.
Spool Work Process
The spool work process passes sequential datasets to a printer or to optical archiving. Each ABAP application server may contain only one spool work process.
Role of Work Processes
The types of its work processes determine the services that an ABAP application server offers. The application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.
You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an SAP System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.
thanks
karthik
reward me points if usefull -
Performance optimization during database selection.
hi gurus,
pls any explain about this...
Strong knowledge of performance optimization during database selection.
regards,
praveenHi Praveen,
Performance Notes
1.Keep the Result Set Small
You should aim to keep the result set small. This reduces both the amount of memory used in the database system and the network load when transferring data to the application server. To reduce the size of your result sets, use the WHERE and HAVING clauses.
Using the WHERE Clause
Whenever you access a database table, you should use a WHERE clause in the corresponding Open SQL statement. Even if a program containing a SELECT statement with no WHERE clause performs well in tests, it may slow down rapidly in your production system, where the data volume increases daily. You should only dispense with the WHERE clause in exceptional cases where you really need the entire contents of the database table every time the statement is executed.
When you use the WHERE clause, the database system optimizes the access and only transfers the required data. You should never transfer unwanted data to the application server and then filter it using ABAP statements.
Using the HAVING Clause
After selecting the required lines in the WHERE clause, the system then processes the GROUP BY clause, if one exists, and summarizes the database lines selected. The HAVING clause allows you to restrict the grouped lines, and in particular, the aggregate expressions, by applying further conditions.
Effect
If you use the WHERE and HAVING clauses correctly:
There are no more physical I/Os in the database than necessary
No unwanted data is stored in the database cache (it could otherwise displace data that is actually required)
The CPU usage of the database host is minimize
The network load is reduced, since only the data that is required by the application is transferred to the application server.
Minimize the Amount of Data Transferred
Data is transferred between the database system and the application server in blocks. Each block is up to 32 KB in size (the precise size depends on your network communication hardware). Administration information is transported in the blocks as well as the data.
To minimize the network load, you should transfer as few blocks as possible. Open SQL allows you to do this as follows:
Restrict the Number of Lines
If you only want to read a certain number of lines in a SELECT statement, use the UP TO <n> ROWS addition in the FROM clause. This tells the database system only to transfer <n> lines back to the application server. This is more efficient than transferring more lines than necessary back to the application server and then discarding them in your ABAP program.
If you expect your WHERE clause to return a large number of duplicate entries, you can use the DISTINCT addition in the SELECT clause.
Restrict the Number of Columns
You should only read the columns from a database table that you actually need in the program. To do this, list the columns in the SELECT clause. Note here that the INTO CORRESPONDING FIELDS addition in the INTO clause is only efficient with large volumes of data, otherwise the runtime required to compare the names is too great. For small amounts of data, use a list of variables in the INTO clause.
Do not use * to select all columns unless you really need them. However, if you list individual columns, you may have to adjust the program if the structure of the database table is changed in the ABAP Dictionary. If you specify the database table dynamically, you must always read all of its columns.
Use Aggregate Functions
If you only want to use data for calculations, it is often more efficient to use the aggregate functions of the SELECT clause than to read the individual entries from the database and perform the calculations in the ABAP program.
Aggregate functions allow you to find out the number of values and find the sum, average, minimum, and maximum values.
Following an aggregate expression, only its result is transferred from the database.
Data Transfer when Changing Table Lines
When you use the UPDATE statement to change lines in the table, you should use the WHERE clause to specify the relevant lines, and then SET statements to change only the required columns.
When you use a work area to overwrite table lines, too much data is often transferred. Furthermore, this method requires an extra SELECT statement to fill the work area. Minimize the Number of Data Transfers
In every Open SQL statement, data is transferred between the application server and the database system. Furthermore, the database system has to construct or reopen the appropriate administration data for each database access. You can therefore minimize the load on the network and the database system by minimizing the number of times you access the database.
Multiple Operations Instead of Single Operations
When you change data using INSERT, UPDATE, and DELETE, use internal tables instead of single entries. If you read data using SELECT, it is worth using multiple operations if you want to process the data more than once, other wise, a simple select loop is more efficient.
Avoid Repeated Access
As a rule you should read a given set of data once only in your program, and using a single access. Avoid accessing the same data more than once (for example, SELECT before an UPDATE).
Avoid Nested SELECT Loops
A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. You should therefore only use nested SELECT loops if the selection in the outer loop contains very few lines.
However, using combinations of data from different database tables is more the rule than the exception in the relational data model. You can use the following techniques to avoid nested SELECT statements:
ABAP Dictionary Views
You can define joins between database tables statically and systemwide as views in the ABAP Dictionary. ABAP Dictionary views can be used by all ABAP programs. One of their advantages is that fields that are common to both tables (join fields) are only transferred once from the database to the application server.
Views in the ABAP Dictionary are implemented as inner joins. If the inner table contains no lines that correspond to lines in the outer table, no data is transferred. This is not always the desired result. For example, when you read data from a text table, you want to include lines in the selection even if the corresponding text does not exist in the required language. If you want to include all of the data from the outer table, you can program a left outer join in ABAP.
The links between the tables in the view are created and optimized by the database system. Like database tables, you can buffer views on the application server. The same buffering rules apply to views as to tables. In other words, it is most appropriate for views that you use mostly to read data. This reduces the network load and the amount of physical I/O in the database.
Joins in the FROM Clause
You can read data from more than one database table in a single SELECT statement by using inner or left outer joins in the FROM clause.
The disadvantage of using joins is that redundant data is read from the hierarchically-superior table if there is a 1:N relationship between the outer and inner tables. This can considerably increase the amount of data transferred from the database to the application server. Therefore, when you program a join, you should ensure that the SELECT clause contains a list of only the columns that you really need. Furthermore, joins bypass the table buffer and read directly from the database. For this reason, you should use an ABAP Dictionary view instead of a join if you only want to read the data.
The runtime of a join statement is heavily dependent on the database optimizer, especially when it contains more than two database tables. However, joins are nearly always quicker than using nested SELECT statements.
Subqueries in the WHERE and HAVING Clauses
Another way of accessing more than one database table in the same Open SQL statement is to use subqueries in the WHERE or HAVING clause. The data from a subquery is not transferred to the application server. Instead, it is used to evaluate conditions in the database system. This is a simple and effective way of programming complex database operations.
Using Internal Tables
It is also possible to avoid nested SELECT loops by placing the selection from the outer loop in an internal table and then running the inner selection once only using the FOR ALL ENTRIES addition. This technique stems from the time before joins were allowed in the FROM clause. On the other hand, it does prevent redundant data from being transferred from the database.
Using a Cursor to Read Data
A further method is to decouple the INTO clause from the SELECT statement by opening a cursor using OPEN CURSOR and reading data line by line using FETCH NEXT CURSOR. You must open a new cursor for each nested loop. In this case, you must ensure yourself that the correct lines are read from the database tables in the correct order. This usually requires a foreign key relationship between the database tables, and that they are sorted by the foreign key. Minimize the Search Overhead
You minimize the size of the result set by using the WHERE and HAVING clauses. To increase the efficiency of these clauses, you should formulate them to fit with the database table indexes.
Database Indexes
Indexes speed up data selection from the database. They consist of selected fields of a table, of which a copy is then made in sorted order. If you specify the index fields correctly in a condition in the WHERE or HAVING clause, the system only searches part of the index (index range scan).
The primary index is always created automatically in the R/3 System. It consists of the primary key fields of the database table. This means that for each combination of fields in the index, there is a maximum of one line in the table. This kind of index is also known as UNIQUE.
If you cannot use the primary index to determine the result set because, for example, none of the primary index fields occur in the WHERE or HAVING clause, the system searches through the entire table (full table scan). For this case, you can create secondary indexes, which can restrict the number of table entries searched to form the result set.
You specify the fields of secondary indexes using the ABAP Dictionary. You can also determine whether the index is unique or not. However, you should not create secondary indexes to cover all possible combinations of fields.
Only create one if you select data by fields that are not contained in another index, and the performance is very poor. Furthermore, you should only create secondary indexes for database tables from which you mainly read, since indexes have to be updated each time the database table is changed. As a rule, secondary indexes should not contain more than four fields, and you should not have more than five indexes for a single database table.
If a table has more than five indexes, you run the risk of the optimizer choosing the wrong one for a particular operation. For this reason, you should avoid indexes with overlapping contents.
Secondary indexes should contain columns that you use frequently in a selection, and that are as highly selective as possible. The fewer table entries that can be selected by a certain column, the higher that columns selectivity. Place the most selective fields at the beginning of the index. Your secondary index should be so selective that each index entry corresponds to at most five percent of the table entries. If this is not the case, it is not worth creating the index. You should also avoid creating indexes for fields that are not always filled, where their value is initial for most entries in the table.
If all of the columns in the SELECT clause are contained in the index, the system does not have to search the actual table data after reading from the index. If you have a SELECT clause with very few columns, you can improve performance dramatically by including these columns in a secondary index.
Formulating Conditions for Indexes
You should bear in mind the following when formulating conditions for the WHERE and HAVING clauses so that the system can use a database index and does not have to use a full table scan.
Check for Equality and Link Using AND
The database index search is particularly efficient if you check all index fields for equality (= or EQ) and link the expressions using AND.
Use Positive Conditions
The database system only supports queries that describe the result in positive terms, for example, EQ or LIKE. It does not support negative expressions like NE or NOT LIKE.
If possible, avoid using the NOT operator in the WHERE clause, because it is not supported by database indexes; invert the logical expression instead.
Using OR
The optimizer usually stops working when an OR expression occurs in the condition. This means that the columns checked using OR are not included in the index search. An exception to this are OR expressions at the outside of conditions. You should try to reformulate conditions that apply OR expressions to columns relevant to the index, for example, into an IN condition.
Using Part of the Index
If you construct an index from several columns, the system can still use it even if you only specify a few of the columns in a condition. However, in this case, the sequence of the columns in the index is important. A column can only be used in the index search if all of the columns before it in the index definition have also been specified in the condition.
Checking for Null Values
The IS NULL condition can cause problems with indexes. Some database systems do not store null values in the index structure. Consequently, this field cannot be used in the index.
Avoid Complex Conditions
Avoid complex conditions, since the statements have to be broken down into their individual components by the database system.
Reduce the Database Load
Unlike application servers and presentation servers, there is only one database server in your system. You should therefore aim to reduce the database load as much as possible. You can use the following methods:
Buffer Tables on the Application Server
You can considerably reduce the time required to access data by buffering it in the application server table buffer. Reading a single entry from table T001 can take between 8 and 600 milliseconds, while reading it from the table buffer takes 0.2 - 1 milliseconds.
Whether a table can be buffered or not depends its technical attributes in the ABAP Dictionary. There are three buffering types:
Resident buffering (100%) The first time the table is accessed, its entire contents are loaded in the table buffer.
Generic buffering In this case, you need to specify a generic key (some of the key fields) in the technical settings of the table in the ABAP Dictionary. The table contents are then divided into generic areas. When you access data with one of the generic keys, the whole generic area is loaded into the table buffer. Client-specific tables are often buffered generically by client.
Partial buffering (single entry) Only single entries are read from the database and stored in the table buffer.
When you read from buffered tables, the following happens:
1. An ABAP program requests data from a buffered table.
2. The ABAP processor interprets the Open SQL statement. If the table is defined as a buffered table in the ABAP Dictionary, the ABAP processor checks in the local buffer on the application server to see if the table (or part of it) has already been buffered.
3. If the table has not yet been buffered, the request is passed on to the database. If the data exists in the buffer, it is sent to the program.
4. The database server passes the data to the application server, which places it in the table buffer.
5. The data is passed to the program.
When you change a buffered table, the following happens:
1. The database table is changed and the buffer on the application server is updated. The database interface logs the update statement in the table DDLOG. If the system has more than one application server, the buffer on the other servers is not updated at once.
2. All application servers periodically read the contents of table DDLOG, and delete the corresponding contents from their buffers where necessary. The granularity depends on the buffering type. The table buffers in a distributed system are generally synchronized every 60 seconds (parameter: rsdisp/bufreftime).
3. Within this period, users on non-synchronized application servers will read old data. The data is not recognized as obsolete until the next buffer synchronization. The next time it is accessed, it is re-read from the database.
You should buffer the following types of tables:
Tables that are read very frequently
Tables that are changed very infrequently
Relatively small tables (few lines, few columns, or short columns)
Tables where delayed update is acceptable.
Once you have buffered a table, take care not to use any Open SQL statements that bypass the buffer.
The SELECT statement bypasses the buffer when you use any of the following:
The BYPASSING BUFFER addition in the FROM clause
The DISTINCT addition in the SELECT clause
Aggregate expressions in the SELECT clause
Joins in the FROM clause
The IS NULL condition in the WHERE clause
Subqueries in the WHERE clause
The ORDER BY clause
The GROUP BY clause
The FOR UPDATE addition
Furthermore, all Native SQL statements bypass the buffer.
Avoid Reading Data Repeatedly
If you avoid reading the same data repeatedly, you both reduce the number of database accesses and reduce the load on the database. Furthermore, a "dirty read" may occur with database tables other than Oracle. This means that the second time you read data from a database table, it may be different from the data read the first time. To ensure that the data in your program is consistent, you should read it once only and then store it in an internal table.
Sort Data in Your ABAP Programs
The ORDER BY clause in the SELECT statement is not necessarily optimized by the database system or executed with the correct index. This can result in increased runtime costs. You should only use ORDER BY if the database sort uses the same index with which the table is read. To find out which index the system uses, use SQL Trace in the ABAP Workbench Performance Trace. If the indexes are not the same, it is more efficient to read the data into an internal table or extract and sort it in the ABAP program using the SORT statement.
Use Logical Databases
SAP supplies logical databases for all applications. A logical database is an ABAP program that decouples Open SQL statements from application programs. They are optimized for the best possible database performance. However, it is important that you use the right logical database. The hierarchy of the data you want to read must reflect the structure of the logical database, otherwise, they can have a negative effect on performance. For example, if you want to read data from a table right at the bottom of the hierarchy of the logical database, it has to read at least the key fields of all tables above it in the hierarchy. In this case, it is more efficient to use a SELECT statement.
Work Processes
Work processes execute the individual dialog steps in R/3 applications. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in the R/3 System.
Structure of a Work Process
Work processes execute the dialog steps of application programs. They are components of an application server. The following diagram shows the components of a work process:
Each work process contains two software processors and a database interface.
Screen Processor
In R/3 application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic. The screen flow logic controls a large part of the user interaction. The R/3 Basis system contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.
ABAP Processor
The actual processing logic of an application program is written in ABAP - SAPs own programming language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.
Database Interface
The database interface provides the following services:
Establishing and terminating connections between the work process and the database.
Access to database tables
Access to R/3 Repository objects (ABAP programs, screens and so on)
Access to catalog information (ABAP Dictionary)
Controlling transactions (commit and rollback handling)
Table buffer administration on the application server.
The following diagram shows the individual components of the database interface:
The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.
Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that the R/3 installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in the R/3 System by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.
Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an application server. Where an R/3 System is distributed across more than one application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change.
Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. Unlike Open SQL statements, Native SQL statements are not checked and converted, but instead are sent directly to the database system. Programs that use Native SQL are specific to the database system for which they were written. R/3 applications contain as little Native SQL as possible. In fact, it is only used in a few Basis components (for example, to create or change table definitions in the ABAP Dictionary).
The database-dependent layer in the diagram serves to hide the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install the Basis system. Thanks to the standardization of SQL, the differences in the syntax of statements are very slight. However, the semantics and behavior of the statements have not been fully standardized, and the differences in these areas can be greater. When you use Native SQL, the function of the database-dependent layer is minimal.
Types of Work Process
Although all work processes contain the components described above, they can still be divided into different types. The type of a work process determines the kind of task for which it is responsible in the application server. It does not specify a particular set of technical attributes. The individual tasks are distributed to the work processes by the dispatcher.
Before you start your R/3 System, you determine how many work processes it will have, and what their types will be. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your application servers.
The following diagram shows again the structure of an application server, but this time, includes the various possible work process types:
The various work processes are described briefly below. Other parts of this documentation describe the individual components of the application server and the R/3 System in more detail.
Dialog Work Process
Dialog work processes deal with requests from an active user to execute dialog steps.
Update Work Process
Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.
Background Work Process
Background work processes process programs that can be executed without user interaction (background jobs).
Enqueue Work Process
The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.
Spool Work Process
The spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain several spool work process.
The services offered by an application server are determined by the types of its work processes. One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.
You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.
ABAP Application Server
R/3 programs run on application servers. They are an important component of the R/3 System. The following sections describe application servers in more detail.
Structure of an ABAP Application Server
The application layer of an R/3 System is made up of the application servers and the message server. Application programs in an R/3 System are run on application servers. The application servers communicate with the presentation components, the database, and also with each other, using the message server.
The following diagram shows the structure of an application server:
The individual components are:
Work Processes
An application server contains work processes, which are components that can run an application. Work processes are components that are able to execute an application (that is, one dialog step each). Each work process is linked to a memory area containing the context of the application being run. The context contains the current data for the application program. This needs to be available in each dialog step. Further information about the different types of work process is contained later on in this documentation.
Dispatcher
Each application server contains a dispatcher. The dispatcher is the link between the work processes and the users logged onto the application server. Its task is to receive requests for dialog steps from the SAP GUI and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.
Gateway
Each application server contains a gateway. This is the interface for the R/3 communication protocols (RFC, CPI/C). It can communicate with other application servers in the same R/3 System, with other R/3 Systems, with R/2 Systems, or with non-SAP systems.
The application server structure as described here aids the performance and scalability of the entire R/3 System. The fixed number of work processes and dispatching of dialog steps leads to optimal memory use, since it means that certain components and the memory areas of a work process are application-independent and reusable. The fact that the individual work processes work independently makes them suitable for a multi-processor architecture. The methods used in the dispatcher to distribute tasks to work processes are discussed more closely in the section Dispatching Dialog Steps.
Shared Memory
All of the work processes on an application server use a common main memory area called shared memory to save contexts or to buffer constant data locally.
The resources that all work processes use (such as programs and table contents) are contained in shared memory. Memory management in the R/3 System ensures that the work processes always address the correct context, that is the data relevant to the current state of the program that is running. A mapping process projects the required context for a dialog step from shared memory into the address of the relevant work process. This reduces the actual copying to a minimum.
Local buffering of data in the shared memory of the application server reduces the number of database reads required. This reduces access times for application programs considerably. For optimal use of the buffer, you can concentrate individual applications (financial accounting, logistics, human resources) into separate application server groups.
Database Connection
When you start up an R/3 System, each application server registers its work processes with the database layer, and receives a single dedicated channel for each. While the system is running, each work process is a user (client) of the database system (server). You cannot change the work process registration while the system is running. Neither can you reassign a database channel from one work process to another. For this reason, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. This has important consequences for the programming model explained below.
Dispatching Dialog Steps
The number of users logged onto an application server is often many times greater than the number of available work processes. Furthermore, it is not restricted by the R/3 system architecture. Furthermore, each user can run several applications at once. The dispatcher has the important task of distributing all dialog steps among the work processes on the application server.
The following diagram is an example of how this might happen:
1. The dispatcher receives the request to execute a dialog step from user 1 and directs it to work process 1, which happens to be free. The work process addresses the context of the application program (in shared memory) and executes the dialog step. It then becomes free again.
2. The dispatcher receives the request to execute a dialog step from user 2 and directs it to work process 1, which is now free again. The work process executes the dialog step as in step 1.
3. While work process 1 is still working, the dispatcher receives a further request from user 1 and directs it to work process 2, which is free.
4. After work processes 1 and 2 have finished processing their dialog steps, the dispatcher receives another request from user 1 and directs it to work process 1, which is free again.
5. While work process 1 is still working, the dispatcher receives a further request from user 2 and directs it to work process 2, which is free.
From this example, we can see that:
A dialog step from a program is assigned to a single work process for execution.
The individual dialog steps of a program can be executed on different work processes, and the program context must be addressed for each new work process.
A work process can execute dialog steps of different programs from different users.
The example does not show that the dispatcher tries to distribute the requests to the work processes such that the same work process is used as often as possible for the successive dialog steps in an application. This is useful, since it saves the program context having to be addressed each time a dialog step is executed.
Dispatching and the Programming Model
The separation of application and presentation layer made it necessary to split up application programs into dialog steps. This, and the fact that dialog steps are dispatched to individual work processes, has had important consequences for the programming model.
As mentioned above, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. The contents of the database must be consistent at its beginning and end. The beginning and end of a database LUW are defined by a commit command to the database system (database commit). During a database LUW, that is, between two database commits, the database system itself ensures consistency within the database. In other words, it takes over tasks such as locking database entries while they are being edited, or restoring the old data (rollback) if a step terminates in an error.
A typical SAP application program extends over several screens and the corresponding dialog steps. The user requests database changes on the individual screens that should lead to the database being consistent once the screens have all been processed. However, the individual dialog steps run on different work processes, and a single work process can process dialog steps from other applications. It is clear that two or more independent applications whose dialog steps happen to be processed on the same work process cannot be allowed to work with the same database LUW.
Consequently, a work process must open a separate database LUW for each dialog step. The work process sends a commit command (database commit) to the database at the end of each dialog step in which it makes database changes. These commit commands are called implicit database commits, since they are not explicitly written into the application program.
These implicit database commits mean that a database LUW can be kept open for a maximum of one dialog step. This leads to a considerable reduction in database load, serialization, and deadlocks, and enables a large number of users to use the same system.
However, the question now arises of how this method (1 dialog step = 1 database LUW) can be reconciled with the demand to make commits and rollbacks dependent on the logical flow of the application program instead of the technical distribution of dialog steps. Database update requests that depend on one another form logical units in the program that extend over more than one dialog step. The database changes associated with these logical units must be executed together and must also be able to be undone together.
The SAP programming model contains a series of bundling techniques that allow you to group database updates together in logical units. The section of an R/3 application program that bundles a set of logically-associated database operations is called an SAP LUW. Unlike a database LUW, a SAP LUW includes all of the dialog steps in a logical unit, including the database update.
Happy Reading...
shibu -
Transaction support? Can i coordinate EJB transactions and COM+ transactions?
Can I call a transactional com object within an ejb transaction and have
success/rollback handled correctly? Or will I have to hand-code this? Are
any examples available?
Niels Harremoës
PricewaterhouseCoopersWebLogic jCOM does not support coordination of transactions over COM+. There
are no examples of manual transaction coordination in the WebLogic jCOM
examples, and at present BEA has no plans to create one.
Chris Hopper
BEA Systems, Inc.
"Niels Ull Harremoës" <[email protected]> wrote in news:3bcc91f4
@newsgroups.bea.com:
Can I call a transactional com object within an ejb transaction and have
success/rollback handled correctly? Or will I have to hand-code this? Are
any examples available?
Niels Harremoës
PricewaterhouseCoopers -
Handling Rollback exception in Session Beans
From my session bean,I am making calls to other entity beans in a single Transaction in Websphere.The code is like this:
UserTransaction trans=getSessionContext().getUserTransaction();
trans.begin();
//ejb calls to entity beans
trans.commit();
The problem is that the commit never happens and it always throws a rollback exception and I am unable to proceed further and I am not able to understand the reason behind this at all.Please help out.Hi
First tell whether ur Tables supports Transactions.
u plz forward the exception,
b'cos i tried
UserTransaction ut = (UserTransaction)initial.lookup("java:comp/UserTransaction");
& it works perfectly in tomcat.
Parag -
Problem with rollback in EJB and CMT
Hello,
I faced a problem in my application that I really do not understand (but I really would like to). How can I trigger a rollback of a transaction that is container-managed (CMT)? I know that any system exceptions are supposed to be handled by the container automatically and will cause a transaction rollback when they are thrown from an enterprise bean method. My Problem now is that I'm unable to make this work in my application.
Consider a situation like this:
The ManageEntityBean holds a simple save() method that creates an instance of EntityA and another of EntityB. Both instances store an arbitrary number (here 10). After this, the entityManger (injected from the container) is asked to make these instances persistent. EntityB is mapped with a "unique" constraint, so any attempt to store the same number twice will cause an SQL Exception.
First time when the save() method is invoked, the instances aEntity and bEntity are made permanent in the database. Second time when the save() method is invoked, the database throws an exception because bEntity is violating the unique constraint. What I would expect now is a complete rollback of the whole transaction. Instead, only bEntity has not been made permanent, but aEntity has.
What's wrong with this code?
@Stateless
public class ManageEntityBean implements ManageEntity {
@PersistenceContext
private EntityManager entityManager;
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public void save() {
try {
EntityA aEntity = new EntityA(10);
EntityB bEntity = new EntityB(10);
entityManager.persist(aEntity);
entityManager.persist(bEntity);
} catch (Exception e) {
throw new EJBException(e);
@Entity
public class EntityA implements java.io.Serializable {
@Id
@GeneratedValue
private long id;
@Column(name="NUMBER")
private int number;
public EntityA() {}
public EntityA(int number) {
this.number = number;
@Entity
public class EntityB implements java.io.Serializable {
@Id
@GeneratedValue
private long id;
@Column(name = "NUMBER", unique = true)
private int number;
public EntityB() {}
public EntityB(int number) {
this.number = number;
}I found two related topics in this forum but still I didn't find the solution yet.
[Enterprise JavaBeans - CMT and JDBC|http://forums.sun.com/thread.jspa?forumID=13&threadID=525651]
and
[ Forums - A CMT Session Bean Does Not Maintain the Transaction Correctly| http://forums.sun.com/thread.jspa?forumID=13&threadID=161512]
Maybe anyone can give me a hint. Help is very much appreciated
ChristophThank you for your input!
The save() method is simply invoked from the test applications main() method:
public class Test {
public static void main(String[] args) {
JndiUtil<ManageEntity> jndiUtil = new JndiUtil<ManageEntity>();
ManageEntity handler = jndiUtil.lookupBeanContext("ManageEntityBean", ManageEntity.class);
handler.save();
}Btw. I use Hibernate as persistence provider and JBoss 4.2.2.GA as application server.
For clarity I attach some lines of the debug logging that is produced when the test application is getting started for the second time:
### open Session
17:44:00,555 DEBUG *[SessionImpl] opened session at timestamp: 5007498610909184*
17:44:00,555 DEBUG [AbstractEntityManagerImpl] Looking for a JTA transaction to join
17:44:00,555 DEBUG [JDBCContext] successfully registered Synchronization
17:44:00,555 DEBUG [AbstractEntityManagerImpl] Looking for a JTA transaction to join
17:44:00,555 DEBUG [AbstractEntityManagerImpl] Transaction already joined
### invoke em.persist(aEntity)
17:44:00,555 DEBUG [AbstractSaveEventListener] executing identity-insert immediately
17:44:00,555 DEBUG [AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
17:44:00,555 DEBUG *[ConnectionManager] opening JDBC connection*
17:44:00,555 DEBUG [SQL]
/* insert de.zippus.domain.EntityA
17:44:00,556 INFO [STDOUT] Hibernate:
/* insert de.zippus.domain.EntityA
17:44:00,558 DEBUG [IdentifierGeneratorFactory] Natively generated identity: 2
17:44:00,559 DEBUG [AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
17:44:00,559 DEBUG [ConnectionManager] aggressively releasing JDBC connection
17:44:00,559 DEBUG [ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: >0)]
### invoke em.persist(bEntity)
17:44:00,559 DEBUG [AbstractSaveEventListener] executing identity-insert immediately
17:44:00,559 DEBUG [AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
17:44:00,559 DEBUG [ConnectionManager] opening JDBC connection
17:44:00,559 DEBUG [SQL]
/* insert de.zippus.domain.EntityB
17:44:00,560 INFO [STDOUT] Hibernate:
/* insert de.zippus.domain.EntityB
17:44:00,561 DEBUG [AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
17:44:00,561 DEBUG [ConnectionManager] aggressively releasing JDBC connection
17:44:00,561 DEBUG [ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: >0)]
17:44:00,561 DEBUG [JDBCExceptionReporter] could not insert: [de.zippus.domain.EntityB] [* insert de.zippus.domain.EntityB */ insert into >ENTITY_B (NUMBER) values (?)]
com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException: Duplicate entry '10' for key 2
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931)
17:44:00,563 WARN [JDBCExceptionReporter] SQL Error: 1062, SQLState: 23000
17:44:00,563 ERROR [JDBCExceptionReporter] Duplicate entry '10' for key 2
17:44:00,563 DEBUG [AbstractEntityManagerImpl] mark transaction for rollback
17:44:00,563 ERROR [ManageEntityBean] Caught exception: javax.persistence.EntityExistsException: >org.hibernate.exception.ConstraintViolationException: could not insert: [de.zippus.domain.EntityB]
17:44:00,563 ERROR [ManageEntityBean] Exception Cause: org.hibernate.exception.ConstraintViolationException: could not insert: >[de.zippus.domain.EntityB]
17:44:00,564 DEBUG *[ManagedEntityManagerFactory] ************** closing entity managersession *************** Up to now I'm not that experienced in reading and understanding this kind of logging, but what I can see is, that there is a transaction that spans the whole unit of work and that this transaction is marked for rollback. I think that's quite a good thing, isn't it?
But what really puzzles me here is, that both calls of em.persist() result in an opening of a jdbc connection and an immidiate execution of a database insert. Tell me if I'm wrong, but is this really the right place to happen?
For what reason soever hibernate thinks it has to make these instances permanent, no matter if there is already a session that is taking care of this. If so, I might deal with a wrong hibernate configuration, I checked, but I can't find anything..
What do you think?
Thanks in advance!
Christoph -
Rollback segment Error coming for 8 lacks Record while creating MV
Hi All,
i am creating a materialized View and it gives us 8 lacks record but when we creates in production its fails due to rollback segment does not have enough space to handle it and it did not create the MV.
can anyone help me out to resolve this issue for the below query while creating MV.
SELECT DISTINCT NVL
((ROUND ((jt_date_completed - jt_date_requested) * 24, 2)
0
) AS actual_hrs_to_complete,
NVL ((ROUND ((jt_date_responded - jt_date_requested) * 24, 2)
0
) AS actual_hrs_to_respond,
peo1.peo_name AS agent_name,
peo1.peo_user_name AS asagent_soe_id,
le.lglent_desc AS ap_system,
' ' AS assign_work_request_comment,
DECODE (jt.jt_bill_id,
138802, 'CLIENT BILLABLE',
138803, 'CONTRACTED',
138804, 'INTERNAL BILLABLE',
NULL, ' '
) AS billable,
bl.bldg_name_cc AS building, bl.bldg_id_ls AS building_id,
DECODE (bl.bldg_active_cc,
'Y', 'ACTIVE',
'INACTIVE'
) AS building_status,
DECODE (jt.jt_wrk_cause_id,
141521, 'STANDARD WEAR AND TEAR',
141522, 'NEGLIGENCE',
141523, 'ACCIDENTAL',
141524, 'MECHANICAL MALFUNCTION',
141525, 'OVERSIGHT',
141526, 'VANDAL',
141527, 'STANDARD',
141528, 'PROJECT WORK',
6058229, 'TEST',
NULL, ' '
) AS cause_type,
' ' AS comments, peo3.peo_name AS completed_by,
jt.jt_requestor_email AS contact_email,
jt.jt_requestor_name_first
|| ' '
|| jt.jt_requestor_name_last AS contact_name,
jt.jt_requestor_phone AS contact_phone,
cc.cstctrcd_apcode AS corp_code,
cc.cstctrcd_code AS cost_center,
jt.jt_date_closed AS date_closed,
jt.jt_date_completed AS date_completed,
jt.jt_date_requested AS date_requested,
jt.jt_date_responded AS date_responded,
jt.jt_date_response_ecd AS date_response_ecd,
jt.jt_date_scheduled AS date_scheduled,
DECODE (jt.jt_def_id,
139949, 'WTG VENDOR RESPONSE',
139950, 'WAITING ON PARTS',
139951, 'LABOR AVAILABILITY',
139952, 'DEFERRED- HI PRI WORK',
139953, 'WTG APPROVAL',
139954, 'FUNDING REQUIRED',
139955, 'ACCESS DENIED',
139956, 'WTG MATERIAL',
NULL, ' '
) AS deferral_reason,
jt.jt_description AS description,
jt.jt_date_resched_ecd AS ecd,
fmg.facility_manager AS facility_manager,
fl.floors_text AS FLOOR, gl.genled_desc AS general_ledger,
' ' AS kiosk_date_requested, ' ' AS kiosk_dispatch_confirmed,
' ' AS kiosk_dispatched,
eqp.equip_customer_code AS linked_equipment_alias,
eqp.equip_id AS linked_equipment_id,
eqp.equip_text AS linked_equipment_name,
DECODE (jt_originator_type_id,
1000, 'PROJECT MOVE REQUEST',
138834, 'CUSTOMER INITIATED CORRECTION',
138835, 'CUSTOMER INITIATED REQUEST',
138836, 'CORRECTIVE MAINTENANCE',
138837, 'CONFERENCE ROOM BOOKING',
138838, 'PROJECT INITIATED REQUEST',
138839, 'PLANNED PREVENTIVE MAINTENANCE',
138840, 'SELF INITATED REQUEST',
NULL, ' '
) AS originator_type,
' ' AS payment_terms, priority_text AS priority_code,
swoty.sworktype_text AS problem_type,
prop.property_name_cc AS property,
jt.jt_cost_quote_total AS quote_total,
par.levels_name AS region,
DECODE (jt.jt_repdef_id,
141534, 'ADJUSTED SETTING',
141535, 'TRAINING FOR END',
141536, 'NEW REQUEST',
141537, 'NO REPAIR REQUIR',
141538, 'REPLACED PARTS',
141539, 'REPLACE EQUIPMEN',
1000699, 'NEW REQUEST',
NULL, ' '
) AS repair_definitions,
jt.jt_repairdesc AS repair_description,
jt.jt_requestor AS requestor, ' ' AS requestor_cost_center,
jt.jt_requestor_email AS requestor_email,
jt.jt_requestor_name_first AS requestor_name,
jt.jt_requestor_phone AS requestor_phone,
' ' AS response_time, rm.room_name_cc AS room,
p1.peo_provider_code1 AS service_provider,
p1.peo_address_1 AS service_provider_address,
peocity.city_text service_provider_city,
p1.peo_provider_code1 AS service_provider_code,
peocity.city_country_name AS service_provider_country,
peocur.currency_text AS service_provider_currency,
p1.peo_name AS service_provider_description,
p1.peo_dispatch_method AS serv_prov_dispatc_hmethod,
p1.peo_rate_double AS serv_prov_double_time_rate,
p1.peo_email AS service_provider_email,
p1.peo_emergency_phone AS serv_prov_emergency_phone,
p1.peo_fax AS service_provider_fax_number,
p1.peo_home_phone AS service_provider_home_phone,
p1.peo_rate_hourly AS service_provider_hourly_rate,
p1.peo_title AS service_provider_job_title,
p1.peo_method_id AS service_provider_method,
p1.peo_cell_phone AS service_provider_mobile_phone,
p1.peo_pager AS service_provider_pager,
p1.peo_rate_differential AS service_provider_rates,
p1.peo_rate_differential AS ser_prov_shift_differential,
peocity.city_state_prov_text AS serv_prov_state_province,
DECODE (p1.peo_active,
'Y', 'ACTIVE',
'INACTIVE'
) AS service_provider_status,
p1.peo_url AS serv_prov_web_site_address,
p1.peo_phone AS service_provider_work_phone,
p1.peo_postal_code AS serv_prov_zip_postal_code, ' ' AS shift,
' ' AS skill,
DECODE (jt.jt_bigstatus_id,
138813, 'NEW',
138814, 'PENDING',
138815, 'OPEN',
138816, 'COMPLETED',
138817, 'CLOSED',
138818, 'CANCELLED',
NULL, ' '
) AS status,
lev.levels_name AS subregion, ' ' AS trade,
p1.peo_ls_interface_code1 AS vendor_id,
p1.peo_fax AS vendor_purchasing_fax,
p1.peo_vendor_site_code AS vendor_sitecode,
jt.jt_id AS vendor_ticket, p1.peo_name AS vendor_companyname,
jt.jt_requestor_vip AS vip, wo.wo_id AS work_order_no,
jt.jt_id AS work_request,
jt.jt_class_id AS work_request_class,
woty.worktype_text AS work_type, ' ' AS wr_cost,
jt.jt_description AS wr_description,
' ' AS wr_dispatch_method,
DECODE (jt.jt_bigstatus_id,
138813, 'NEW',
138814, 'PENDING',
138815, 'OPEN',
138816, 'COMPLETED',
138817, 'CLOSED',
138818, 'CANCELLED',
NULL, ' '
) AS wr_status,
ctry.country_name AS country
FROM citi.jobticket jt,
citi.property prop,
citi.bldg bl,
citi.bldg_levels bldglvl,
citi.LEVELS lev,
citi.LEVELS par,
(SELECT crstools.stragg (peo_name) facility_manager,
bldgcon_bldg_id
FROM citi.bldg_contacts, citi.people
WHERE bldgcon_peo_id = peo_id
AND bldgcon_contype_id IN (40181, 10142)
GROUP BY bldgcon_bldg_id) fmg,
citi.floors fl,
citi.room rm,
citi.general_ledger gl,
citi.legal_entity le,
citi.cost_center_codes cc,
citi.equipment eqp,
citi.worktype woty,
citi.subworktype swoty,
citi.work_order wo,
citi.jt_workers jtwo,
citi.priority,
citi.country ctry,
citi.people p1,
citi.people peo3,
citi.people peo1,
citi.city peocity,
citi.currency peocur
WHERE jt.jt_bldg_id = bl.bldg_id
AND bl.bldg_id = bldglvl.bldg_levels_bldg_id
AND bldglvl.bldg_levels_levels_id = lev.levels_id
AND lev.levels_parent = par.levels_id(+)
AND prop.property_id = bl.bldg_property_id
AND bl.bldg_active_ls <> 'N'
AND jt.jt_floors_id = fl.floors_id(+)
AND jt.jt_room_id = rm.room_id(+)
AND jt.jt_bldg_id = fmg.bldgcon_bldg_id(+)
AND jt.jt_genled_id = gl.genled_id(+)
AND gl.genled_lglent_id = le.lglent_id(+)
AND jt.jt_cstctrcd_id = cc.cstctrcd_id(+)
AND jt.jt_equip_id = eqp.equip_id(+)
AND jt.jt_id = jtwo.jtw_jt_id(+)
AND jt.jt_worktype_id = woty.worktype_id(+)
AND jt.jt_sworktype_id = swoty.sworktype_id(+)
AND jt.jt_wo_id = wo.wo_id
AND jt.jt_priority_id = priority_id(+)
AND jt.jt_date_requested >= ADD_MONTHS (SYSDATE, -12)
AND bl.bldg_country_id = ctry.country_id
AND jtwo.jtw_peo_id = p1.peo_id(+)
AND p1.peo_city_id = peocity.city_id(+)
AND jt.jt_completed_by_peo_id = peo3.peo_id(+)
AND p1.peo_rate_currency_id = peocur.currency_id(+)
AND jt.jt_agent_peo_id = peo1.peo_id(+);
Regards
shyam~Hi,
Its ora-1555? IS your undo_retention sufficient?
Since you are developer the only option you have is to tune the query?
Am curious to know like I create materialized view so that I do not have to run complex query on the master database / or to prevent the access to master database more than once to get the same data?
Like to know which is your case because your query seem to be too complex to be the case for former. Do you think this materialized view would be used frequently in your application?
Regards
Anurag Tibrewal. -
Report and Alert don't executed in the error handler with a JMS proxy service
Hi,
I'm working with OSB 11.1.1.4.0 and I'm facing a problem with the error handler of my JMS proxy service.
My error handler contains two main elements :
- a Report action
- an Alert with a JMS destination defined
When the business service failed the message remain in the queue. It's the expected behavior.
The problem is :
- the report is missing
- the alert is raised but missing in the JMS destination defined in the Alert setting.
I've noticed if I add a Reply with Failure or Success, Report and Alert are successfully executed.
Unfortunately the message don't remain in the JMS queue.
What can I do in order to have my report/alert done and the JMS transaction rollback in order to keep the message in the queue ?
I've already met this problem in the past with alsb v3 and my solution was to add Service Callout in the error handler in order to externalize these actions.
This solution is not convenient and I hope another solution is possible.Inventorying workgroups can be difficult, especially when it comes to remote access and network security. Because workgroups are not centrally managed, some of the items discussed in this
wiki article on preparing your workgroup environment may require you to visit each machine individually.
For non-domain credentials, you do not use the <systemname>\<user> format, you simply enter the user name. Regarding how to enter the credentials, if you have an account that uses the same username and password on all machines and is an administrator
on all of those machines, then you can enter that in the All computers credentials page of the wizard. You can also do this if they are different user names. However, if some machines have an account with the same user name, such as Administrator,
but different passwords on each machine, you will need to use the Manually enter computer names discovery method, and then enter the information for each group or each machine.
As you can tell, workgroup environments can quickly negate any benefit that the agentless inventory nature of MAP provides.
Please remember to click "Mark as Answer" on the post that helps you, and to click
"Unmark as Answer" if a marked post does not actually answer your question. Please
VOTE as HELPFUL if the post helps you. This can be beneficial to other community members reading the thread. -
MDB rollbacks and stops the listener port with error code 2072
Hi
We have a MDB listening on QUEUE1. This MDB processes the message and puts another message in QUEUE2. Transaction is "required" for this MDB.
The processing could somtime take more than 2 min. We used to get EJB timeout error in this scenario. We changed EJB timeout to 5 min (default was 2 min). This resolved the timeout error. But it started throwing following exception. Note that if the processing takes less than 2 min, MDB never rollbacks.
After this rollack, listener port can not pick up the next message and it throws error (MQJMS2002: failed to get message from MQ queue. MQ Error Code 2072) . It stops as a result and restarts after 60 sec. Even after restart it can not process the messages till we restart the JVM.
Regarding error handling, Backout threshold is 3. If the message is redelivered, we discard this message.
We are using 2 Phase commit for 2 resources MQ (5.3) and MS SQL.
Websphere version is 5.1.
Two issues here
1. Why is MDB rolling back if processing takes more than 2 min.
2. After the rollback, why is listener port not picking up the messages. Why do we need to recycle the JVM.
Any pointers to resolve this issue?
EXCEPTION
[11/29/05 15:03:37:752 EST] 1b9bccc XATransaction E J2CA0027E: An exception occurred while invoking end on an XA Resource Adapter from dataSource JMS$postprocessor$JMSManagedConnection@25078403, within transaction ID {XID: formatId(57415344), gtrid_length(51), bqual_length(2, data(00000000000000950000000113238145f813eccfef12249c6aab206666f96901636c5f6170703130355f73656e7431715f716113238145f813eccfef12249c6aab206666f969010000000100000000)}: javax.transaction.xa.XAException: XA operation failed, see errorCode
at com.ibm.mq.MQXAResource.end(MQXAResource.java:520)
at com.ibm.ejs.jms.JMSManagedSession$JMSXAResource.end(JMSManagedSession.java:1557)
at com.ibm.ejs.j2c.XATransactionWrapper.end(XATransactionWrapper.java:525)
at com.ibm.ws.Transaction.JTA.JTAResourceBase.end(JTAResourceBase.java:253)
at com.ibm.ws.Transaction.JTA.RegisteredResources.distributeEnd(RegisteredResources.java:629)
at com.ibm.ws.Transaction.JTA.TransactionImpl.internalPrepare(TransactionImpl.java:1241)
at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java:981)
at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java:150)
at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java:177)
at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:712)
at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:167)
at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:570)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3068)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:102)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:127)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:375)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)
[11/29/05 15:03:38:089 EST] 1b9bccc ServerSession W WMSG0031E: Exception processing JMS Message for MDB BatchProcessorMDB, JMSDestination jms/PostprocessorQ : javax.ejb.TransactionRolledbackLocalException: ; nested exception is: com.ibm.ws.exception.WsEJBException
com.ibm.ws.exception.WsEJBException
at com.ibm.ejs.container.LocalExceptionMappingStrategy.mapException(LocalExceptionMappingStrategy.java:159)
at com.ibm.ejs.container.LocalExceptionMappingStrategy.mapCSITransactionRolledBackException(LocalExceptionMappingStrategy.java:293)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3159)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:102)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:127)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:375)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)
javax.ejb.TransactionRolledbackLocalException: ; nested exception is: com.ibm.ws.exception.WsEJBException
at com.ibm.ejs.container.LocalExceptionMappingStrategy.mapCSIException(LocalExceptionMappingStrategy.java:96)
at com.ibm.ejs.container.LocalExceptionMappingStrategy.mapException(LocalExceptionMappingStrategy.java:165)
at com.ibm.ejs.container.LocalExceptionMappingStrategy.mapCSITransactionRolledBackException(LocalExceptionMappingStrategy.java:293)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3159)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:102)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:127)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:375)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)
[11/29/05 15:03:38:124 EST] 1e9aa18 JMSExceptionL E WMSG0018E: Error on JMSConnection for MDB BatchProcessorMDB , JMSDestination jms/PostprocessorQ : javax.jms.JMSException: MQJMS2002: failed to get message from MQ queue
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:553)
at com.ibm.mq.jms.MQSession.consume(MQSession.java:3144)
at com.ibm.mq.jms.MQSession.run(MQSession.java:1585)
at com.ibm.ejs.jms.JMSSessionHandle.run(JMSSessionHandle.java:924)
at com.ibm.ejs.jms.listener.ServerSession.connectionConsumerOnMessage(ServerSession.java:752)
at com.ibm.ejs.jms.listener.ServerSession.onMessage(ServerSession.java:527)
at com.ibm.ejs.jms.listener.ServerSession.dispatch(ServerSession.java:494)
at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.ibm.ejs.jms.listener.ServerSessionDispatcher.dispatch(ServerSessionDispatcher.java:37)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:91)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:127)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:375)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)
---- Begin backtrace for Nested Throwables
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2072
at com.ibm.mq.jms.MQSession.consume(MQSession.java:3118)
at com.ibm.mq.jms.MQSession.run(MQSession.java:1585)
at com.ibm.ejs.jms.JMSSessionHandle.run(JMSSessionHandle.java:924)
at com.ibm.ejs.jms.listener.ServerSession.connectionConsumerOnMessage(ServerSession.java:752)
at com.ibm.ejs.jms.listener.ServerSession.onMessage(ServerSession.java:527)
at com.ibm.ejs.jms.listener.ServerSession.dispatch(ServerSession.java:494)
at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.ibm.ejs.jms.listener.ServerSessionDispatcher.dispatch(ServerSessionDispatcher.java:37)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:91)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:127)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:375)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)
[11/29/05 15:03:38:149 EST] 1e9aa18 JMSExceptionL E WMSG0057E: Error on JMSConnection for MDB BatchProcessorMDB , JMSDestination jms/PostprocessorQ , JMS Linked Exception : com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2072
at com.ibm.mq.jms.MQSession.consume(MQSession.java:3118)
at com.ibm.mq.jms.MQSession.run(MQSession.java:1585)
at com.ibm.ejs.jms.JMSSessionHandle.run(JMSSessionHandle.java:924)
at com.ibm.ejs.jms.listener.ServerSession.connectionConsumerOnMessage(ServerSession.java:752)
at com.ibm.ejs.jms.listener.ServerSession.onMessage(ServerSession.java:527)
at com.ibm.ejs.jms.listener.ServerSession.dispatch(ServerSession.java:494)
at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.ibm.ejs.jms.listener.ServerSessionDispatcher.dispatch(ServerSessionDispatcher.java:37)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:91)
at com.ibm.ejs.container.MDBWrapper.onMessage(MDBWrapper.java:127)
at com.ibm.ejs.jms.listener.ServerSession.run(ServerSession.java:375)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)
[11/29/05 15:03:38:190 EST] 1e9aa18 MDBListenerIm I WMSG0043I: MDB Listener ProcessorLP stopped for JMSDestination jms/PostprocessorQ
[11/29/05 15:03:38:192 EST] 1e9aa18 MDBListenerIm I WMSG0058I: Listener Port ProcessorLP will attempt to restart in 60 seconds
[11/29/05 15:03:38:194 EST] 1e9aa18 ConnectionEve A J2CA0056I: The Connection Manager received a fatal connection error from the Resource Adaptor for resource jms/PostprocessorQF. The exception which was received is javax.jms.JMSException: MQJMS2002: failed to get message from MQ queue
[11/29/05 15:04:38:230 EST] 1436f66 MDBListenerIm I WMSG0042I: MDB Listener ProcessorLP started successfully for JMSDestination jms/PostprocessorQHave been able to solve this problem? The same occurs in our environment. I have a nagging feelin git has something to do with a known bug that is solved in some fixpack or something. We're on Websphere 5.1.1.4.
Any feedback would be appreciated.
Thanks,
Jaap -
How to configure Spring Data JPA to handle sdo_geometry and Timestamp(0)?
Hi all,
I'm new to this community, not sure if I'm posting in the right place.
I'm an Oracle old-hand, but new to Spring Data, having done a bit on postGIS, but now trying to apply it to Oracle.
My problem: I have a new maven project, with Entity and Repository classes, and a JUnit test program that uses DbUnit to preload test data.
The current config uses a beans.xml file to set up:
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">...
<property name="jpaProperties">....
<bean id="vendorAdapter"
class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="databasePlatform" value="org.hibernate.dialect.Oracle10gDialect" />
<property name="generateDdl" value="false" />
</bean>
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource"
destroy-method="close">
<property name="driverClass" value="oracle.jdbc.OracleDriver" />
<property name="jdbcUrl"
value="jdbc:oracle:thin:@localhost:2632:BLADE" />...
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
Test of repos.count() works ok.
Test to call repos.findByName(String) fails, (stack below).
Now, the current setup doesn't handle SDO_GEOMETRY, or TIMESTAMP(0), but will manage TIMESTAMP(6).
The warnings below show that I'm using "DefaultDataTypeFactory" and should probably be using OracleDataTypeFactory.
I've also found the OracleDataSource class, and tried that, but still get the same data type issues.
Ok, the big questions:
1. Can anyone point me at an example to configure the dataSource, or vendorAdapter, to use the OracleDataTypeFactory, and retrieve these data types?
2. What data type should I be using in Java for the geometry column?
Thanks,
Phil
Test output warnings:
16:24:05.846 [main] INFO org.springframework.test.context.transaction.TransactionalTestExecutionListener - Began transaction (2) for test context [DefaultTestContext@990034 testClass = NotamRepositoryTest, testInstance = com.thalesgroup.uk.airscape.common.data.domain.dao.notam.NotamRepositoryTest@3ff1d6, testMethod = testNotamFetchByDatasetName@NotamRepositoryTest, testException = [null], mergedContextConfiguration = [MergedContextConfiguration@1346193 testClass = NotamRepositoryTest, locations = '{classpath:testBeans.xml}', classes = '{}', contextInitializerClasses = '[]', activeProfiles = '{}', contextLoader = 'org.springframework.test.context.support.DelegatingSmartContextLoader', parent = [null]]]; transaction manager [org.springframework.orm.jpa.JpaTransactionManager@1f1fe9d]; rollback [true]
16:24:08.674 [main] WARN org.dbunit.dataset.AbstractTableMetaData - Potential problem found: The configured data type factory 'class org.dbunit.dataset.datatype.DefaultDataTypeFactory' might cause problems with the current database 'Oracle' (e.g. some datatypes may not be supported properly). In rare cases you might see this message because the list of supported database products is incomplete (list=[derby]). If so please request a java-class update via the forums.If you are using your own IDataTypeFactory extending DefaultDataTypeFactory, ensure that you override getValidDbProducts() to specify the supported database products.
16:24:08.674 [main] WARN org.dbunit.util.SQLHelper - DATA_SET.SEC_TAG_MODIFIED data type (1111, 'TIMESTAMP(0)') not recognized and will be ignored. See FAQ for more information.
16:24:08.674 [main] WARN org.dbunit.util.SQLHelper - DATA_SET.CREATED data type (1111, 'TIMESTAMP(0)') not recognized and will be ignored. See FAQ for more information.
16:24:08.674 [main] WARN org.dbunit.util.SQLHelper - DATA_SET.MODIFIED data type (1111, 'TIMESTAMP(0)') not recognized and will be ignored. See FAQ for more information.
16:24:08.690 [main] WARN org.dbunit.util.SQLHelper - DATA_SET.VALID_FROM data type (1111, 'TIMESTAMP(0)') not recognized and will be ignored. See FAQ for more information.
16:24:08.690 [main] WARN org.dbunit.util.SQLHelper - DATA_SET.VALID_TO data type (1111, 'TIMESTAMP(0)') not recognized and will be ignored. See FAQ for more information.
16:24:08.690 [main] WARN org.dbunit.dataset.AbstractTableMetaData - Potential problem found: The configured data type factory 'class org.dbunit.dataset.datatype.DefaultDataTypeFactory' might cause problems with the current database 'Oracle' (e.g. some datatypes may not be supported properly). In rare cases you might see this message because the list of supported database products is incomplete (list=[derby]). If so please request a java-class update via the forums.If you are using your own IDataTypeFactory extending DefaultDataTypeFactory, ensure that you override getValidDbProducts() to specify the supported database products.
16:24:08.690 [main] WARN org.dbunit.util.SQLHelper - NOTAM.Q_POINT data type (1111, 'SDO_GEOMETRY') not recognized and will be ignored. See FAQ for more information.
16:24:08.690 [main] WARN org.dbunit.util.SQLHelper - NOTAM.Q_RANGE_RING data type (1111, 'SDO_GEOMETRY') not recognized and will be ignored. See FAQ for more information.
java.lang.UnsupportedOperationException
at org.hibernate.spatial.GeometrySqlTypeDescriptor.getExtractor(GeometrySqlTypeDescriptor.java:57)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:267)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:263)
at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253)
at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:338)
at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2969)
at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1695)
at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1627)
at org.hibernate.loader.Loader.getRow(Loader.java:1514)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:725)
at org.hibernate.loader.Loader.processResultSet(Loader.java:952)
at org.hibernate.loader.Loader.doQuery(Loader.java:920)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:354)
at org.hibernate.loader.Loader.doList(Loader.java:2553)
at org.hibernate.loader.Loader.doList(Loader.java:2539)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2369)
at org.hibernate.loader.Loader.list(Loader.java:2364)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:496)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:387)
at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:231)
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1264)
at org.hibernate.internal.QueryImpl.list(QueryImpl.java:103)
at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:573)
at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:449)
at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:67)
at org.springframework.data.jpa.repository.query.JpaQueryExecution$CollectionExecution.doExecute(JpaQueryExecution.java:81)
at org.springframework.data.jpa.repository.query.JpaQueryExecution.execute(JpaQueryExecution.java:59)
at org.springframework.data.jpa.repository.query.AbstractJpaQuery.doExecute(AbstractJpaQuery.java:97)
at org.springframework.data.jpa.repository.query.AbstractJpaQuery.execute(AbstractJpaQuery.java:88)
at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:384)
at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:344)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:98)
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:262)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodIntercceptor.invoke(CrudMethodMetadataPostProcessor.java:111)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
at com.sun.proxy.$Proxy67.findByDataSetNameAndDeletedIsNull(Unknown Source)
at com.thalesgroup.uk.airscape.common.data.domain.dao.notam.NotamRepositoryTest.testNotamFetchByDatasetName(NotamRepositoryTest.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:233)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:87)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:176)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)Hi
You can use T-code NACE and then select your application based on your output type you can assign your Print program and Form.
Reward points, if it is helpful.
Regards
Raja.
Maybe you are looking for
-
Hi, How can create target blank (new page open) button click. please help me
-
Administrator console not opening
Guys, I have just installed OBIEE in windows xp. My OC4J and other apps are running. But when i open the Administrator console (Admin tool) , it does not open. It acts as if i didnt click it. Can some one point to what i should do to solve htis issue
-
Hi Is it possible to export a client in Test mode in Basis 700 release? Thanks for any pointers, Abdul
-
can anyone say me in which point SD is integrated with MM module during the creation of sales order? regards, divya.s
-
Changing value of select list to match report field
I have an Apex page that has a report region and a form region. The report region returns a single row of data from a SQL select. One of the fields returned is a user id (which I translate into a user name using a LOV). In the form region, I have a s