Programming NAME_ADDR component in procedure

Hi,
If any way we can programming NAME_ADDR component in the procedure, the same as the mapping package generated by OWB?
Thanks in advance,
William

The name and address is described in the user's guide:
http://download-west.oracle.com/docs/html/B10996_01/08mapope.htm#1186144
Regards:
Igor

Similar Messages

Trigger Unix Program from a stored procedure

Is it possible to start a Unix program as a background OS process from a stored procedure?
In fact I want to call a stored procedure which starts a Unix process. After the termination of this process get the results of the programm (a text file) using UTL_FILE package from the stored procedure and produce an HTML document based on the output of the started process using the htp package.
Thanks, JV

wrote:roadbike
Whats the best way to start a host (Unix) program from a stored procedure or trigger without having to wait for a response from the program (i.e start it and forget it )The BEST way depends on your operating system and version of the Oracle database. If you are at Oracle 10g or higher, I would certainly suggest using dbms_scheduler. In 10gR2 you can set a program to execute on receipt of an event, and the trigger or stored procedure can be the cause of the event.

How can I run an external program from a PLSQL procedure?

Is there a package to run an external program from PLSQL? or is there another way to do that?
thanks.

here there is an example about how a PL/SQL procedure can
work with an external C program.
http://download-east.oracle.com/docs/cd/A87860_01/doc/appdev.817/a76936/dbms_pi2.htm#1003384
Apart from that you have Java Stored Procedures option
to carry out your task.
Java Stored Procedures Developer's Guide Contents / Search / Index / PDF
http://download-east.oracle.com/docs/cd/B10501_01/java.920/a96659.pdf
Joel P�rez

Issue while calling COBOL program from Component Interface in PeopleSoft HRMS 9.2

In HRMS 9.2, I am facing problem while calling the remote call function through component interface. In GP_ABS_EESS_REQ (Navigation Main Menu > Self Service > Time Reporting > Report Time > Absence Request) component, we have “Forecast Balance” button as shown below:
This button checks for eligibility for leave being applied. While using component interface, it executes FORCAST_PB field change event peoplecode which contains a remote call to a cobol program as below:
RemoteCall("PSRCCBL", "PSCOBOLPROG", "GPPOLRUN", "NET_RETURN_CD", &NET_RETURN_CD, "NET_TXN_ID", &NET_TXN_ID, "NET_TXN_NUM", &NET_TXN_NUM, "NET_MSG_ID", &NET_MSG_ID, "NET_MSG_PRM_CNT", &NET_MSG_PRM_CNT, "NET_MSG_PRM1", &NET_MSG_PRM1, "NET_MSG_PRM2", &NET_MSG_PRM2, "NET_MSG_PRM3", &NET_MSG_PRM3);
I am getting following error while executing it via component interface:
(2,148) - Think-time PeopleCode event (RemoteCall), but a SQL update has occurred in the commit interval. (2,148) FUNCLIB_GP_ABS.FCST_PB.FieldFormula Name:Abs_ForecastExec PCPC:5311 Statement:60
Called from:GP_ABS_EESS_REQ.GBL.DERIVED_ABS_SS.FCST_PB.FieldChange Statement:26
(91,34) - Error changing value. {Z_GP_ABS_EESS_REQ_CI.FCST_PB} (91,34)
(18,2) - Data being added conflicts with existing data. (18,2)
(91,37) - Error saving Component Interface. {Z_GP_ABS_EESS_REQ_CI} (91,37)
After commenting out this line of code, I was able to save the CI successfully. But I need to execute this statement before saving CI so that I can check the eligibility for leave being applied. Can anyone help me on this issue?

When I tried to read the file using `CAT -vt <filename>`, I could see that the file contains special characters such as ^M and ^I. This may be because of the file transfer mode(but I transferred in ASCII mode, still the special characters where appearing).
I opened a VI editor and pasted the same script. Save the file, tried to run the script, It was working fine.
I still didn't get how the special characters appeared. I used notepad++ as my editor.

Using socket programming in java stored procedure

Hi there i am currently trying to develope a java stored procedure and place it in oracle and will try to use that procedure to send a message to a server but then it doesnt seems to work. is it possible?
The server and the database is in the same pc and the server is just a small program listening to a port. Hope someone can help me thanks

Hi there i am currently trying to develope a java
stored procedure and place it in oracle and will try
to use that procedure to send a message to a server
but then it doesnt seems to work. is it possible?And what do you do with exceptions in your java proc?
I haven't ever done it myself, but I would be very surprised if it wasn't possible. I also wouldn't be surprised to find out that you have to configure various things to allow it in Oracle itself.

Calling Java programs from Oracle Stored Procedure

Is it possible to call Java programs from Oracle stored procs? If possible Can this be used to exchange data from other applications? Is there a better method/feature in oracle for doing data exchange with other apps?

If what you mean by Oracle stored procedures is pl/sql then yes.
You can create a "wrapper" this way:
CREATE OR REPLACE FUNCTION xmlXform
in_mapUrl IN VARCHAR2,
in_inputUrl IN VARCHAR2
RETURN VARCHAR2
AS
LANGUAGE JAVA NAME
'com.yourcompany.xml2any.xform(java.lang.String,java.lang.String)
RETURN java.lang.String';
Then load the java as:
loadjava -user youruser/youruserpasswd -resolve -verbose lib/xmlparserv2.jar classes/com/yourcompany/xform.class classes/com/yourcompany/xml2any.class
The java, given the correct permissions, can do anything java can do including communicate with outside applications.
Is this the "best" way... depends on what you are trying to accomplish.

How to call 'C' programs from stored procedures?

Hi
Did anybody tried to call 'C' programs
from oracle stored procedures?
If anybody knows, can you please send
how to configure the listener.ora and
tnsnames.ora. If its possible post all the
information from the begining with examples.
thanks....

Oracle JDBC did not support return a result set, if you are using Oracle 9i, you can use pipeline function, then using the TABLE() function the get the row.
Good Luck.
Welcome to http://www.anysql.net/en/

Executing procedure at regular interval from java program

hi,
I want to write java program that will execute procedure at regular interval,
please give me hint how it will happen??????

Use THREAD and Thread.sleep

Execute programs from stored procedures

I will execute a extern program from a stored procedure. Is there anybody who knows that or how to send mail from Oracle without UTL_SMTP?

See my reply to 'chaitanyadatir' just below your post.
null

Procedural Programming with UML Modelling

Hello,
I want to design my program with the UML Modeling but my programming language paradigms is procedural not Object Oriented Program. I can hear many programmer says: "UML not only for oriented programming". Its True?
So, from where should i start, What are
diagrams to be used for procedural
programming Please help mention that the UML diagrams.
Thank You
Hope Your answer

You can create a sequence diagram from a debugger session in JDeveloper by adding a breakpoint to your existing code and then picking Debug -> Debug with diagram. Every time you step into a class the sequence diagram will update, you can then save the diagram after ending your debug session and edit it from publication.
JDeveloper does not support creating java code from the sequence diagram.
Thanks,
Geoff

Trying to understand the basic concept of object oriented programming.

I am trying to understand the basic concept of object oriented programming.
Object - a region of storage that define is defined by both state/behavior.
( An object is the actual thing that behavior affects.)
State - Represented by a set of variables and the values they contain.
(Is the location or movement or action that is the goal that the behavior is trying to accomplish.)
Variables- (What does this mean?)
Value - (What does this mean?)
Behavior - Represented by a set of methods and the logic they implement.
( A set of methods that is built up to tell's the how object to change it's state. )
Methods - A procedure that is executed when an object receives a message.
( A very basic comand.For example the method tells the object to move up, another method tells the method to go left. Thus making the object move up/left that combination is the behavior.)
Class - A template from which the objects are created.
( I am very confused on what classes are.)
- The definitions of the words I obtained from the "Osborne Teach Yourself Java". The () statements are how I interperate the Mechanisms (I do not know if Thats what you call them.) interact with each other. I understand my interpretation may be horribly wrong. I will incredibly appreciate all the support I may get from you.
Thank you

Object oriented programming is a replacement for the older idea of procedural programming (you can research procedural programming in google). As I understand it, in procedural programming, you have a step by step set of function calls to accomplish some task. Each function receives a data structure, manipulates it, and passes it to the next function. The problem with this is that each function preforms some action for the overall task and can't easily be reused by some other task. Its also harder to read the flow of what is happening with raw data structures flying all over the place.
In object oriented programming, an object calls a function of another object and receives back, not a data structure, but another object. Objects contain a data structure that can only be accessed by its functions. An object is not so much a sub component of a bigger task, as it is a service that any other task can use for any purpose. Also, when you pass an object to the caller, the caller can ask questions about the data structure via its functions. The developer doesnt have to know what the previous function did to the data by reading up on any documentation, or having to reverse engineer the code.
I suggest the best way of learning this is to code something like a library object.
A library object contains a collection of book objects
A book object contains a collection of chapter objects
A chapter object contains a collection of paragraph objects
A paragraph object contains a collection of sentence objects
A sentence object contains a collection of word objects.
Add functions to each object to provide a service
Example: A library object should have a:
public void addBook(Book book)
public Book getBook(String title)
public boolean isBookInLibrary(String title)
The key is to add functions to provide a service to anyone who uses your object(s)
For example, what functions (service) should a paragraph object provide?
It shouldn't provide a function that tells how many words there are in a sentence. That function belongs to a sentence object.
Lets say you want to add a new chapter to a book. The task is easy to read
if you write your objects well:
Sentence sentence1=new Sentence("It was a dark and stormy night");
Sentence sentence2=new Sentence("Suddenly, a shot ran out");
Paragraph paragraph=new Paragraph();
paragraph.addSentence(sentence1);
paragraph.addSentence(sentence2);
Paragraphs paragraphs=new Paragraphs();
paragraphs.addParagraph(paragraph);
Library library= new Library();
library.getBook("My Novel").addChapter("Chapter 1",paragraphs).
Now, lets say you want to have a word count for the entire book.
The book should ask each chapter how many words it contains.
Each chapter should ask its paragraphs, each paragraph should ask
its sentences. The total of words should ripple up and be tallied at each
stage until it reaches the book. The book can then report the total.
Only the sentence object actually counts words. The other objects just tallies the counts.
Now, where would you assign a librarian? What object(s) and functions would you provide?
If written well, the project is easily extensible.

Material on dialog programming

Hi al,
does anybody have good material on dialog programming.
SPECIALLY ON TABLE CONTROL
THANKS

Hi
Go thru this docu
                    TRANSACTIONS
TABLE OF CONTENTS
TABLE OF CONTENTS     2
GENERAL INTRODUCTION TO TRANSACTION     5
Logical Unit of Work (LUW)     5
DYNPRO concept     6
SCREEN PAINTER     7
Using Screen Painter     7
Creating a new Screen     7
Designing of Screen     8
Selecting Screen Fields     9
Attributes of Screen Elements     9
Field List     10
Screen Flow Logic     10
MODULE POOL PROGRAMMING     12
Creation of Module Pool Program     12
Communication between Dynpro and Module Program     12
CREATION OF A COMPLETE TRANSACTION     12
Steps involved to create a complete transaction     12
Handling Function Code     13
THE FIELD CHECKS     14
Automatic Field Checks     14
About at Exit Command     15
In module pool program.     15
Flow Logic Validations     16
Module assign.     16
Module Pool Program Validations     17
DYNAMICALLY CALLING THE SCREENS     19
About Displaying Next Screen     19
Set Screen     20
Call Screen     20
Leave to screen     21
SUBSCREENS     22
TABLE CONTROLS     23
Features of Table Controls     23
Declaring of Table Control in the Module Pool Program     24
Designing Table Control on Screen     24
Passing data to Table Control     24
STEP LOOPS     27
Types of Step Loops     27
Switching To List Mode     28
Returning back from LIST mode     28
Process on HELP-REQUEST event     29
Value Request     30
THE SCREEN DISPLAYED IS POP-UP SCREEN AND CODE FOR THE FLOW LOGIC AND MODULE IS WRITTEN BELOW:     32
Need To Change Screen     34
Modifying the screen     34
Field Name       Length Description     34
MODULE MODIFY_SCREEN.     35
LOOP AT SCREEN.     35
ENDMODULE.WORKING WITH MATCHCODE OBJECTS     35
WORKING WITH MATCHCODE OBJECTS     36
Creating Matchcode object     36
Creating Matchcode ids.     37
Using Matchcode     38
Creating Lock Objects     39
Activation of Lock Object     40
                                                                                GENERAL INTRODUCTION TO TRANSACTION
Transaction, in R/3 system is an operation that lets the user make necessary changes to the database. The entire R/3 system is nothing but set of business transaction. The data transfer from old system to SAP R/3 database, or modifying data, or deleting data, which is not required, is done through transaction.
For SAP system, Transaction is nothing but sequence of steps called as dialog steps and for user it is sequence of screens that appears one after the other depending upon the option he selects. The special transaction monitor called the SAP dispatcher handles the sequence of steps that takes place in any transaction. The main task of transaction is to update database table. The database table is not updated until a transaction is completed. All changes can be rolled back if the transaction has not finished.
The transaction contains two steps which are as following:
     Interactive phase: In this step, user enters the data, which needs to be inserted or deleted or modified on to the screen. There can be single screen or multiple screens depending upon the transaction. So this step can consist of single step or multiple steps. In this phase you prepare database record.
     Update phase: This phase processes the database record and updates the database table. Actual updating of database table takes place in this phase.
All the transactions are associated with transaction code. And all these codes are stored in a table TSTC.
Logical Unit of Work (LUW)
The R/3 system is multi user system and many users access the same information at the same time, which is mainly DATA. Consider the case where one user is modifying a record, and second user is trying to delete the same record. If the second user is successful in deleting the record then the first user will face problem for modifying the record that is already deleted. The avoid such situation, R/3 system has provided Logical Unit of Work, which is defined as a locking mechanism to protect transaction integrity. Of course, there are other measures, which ensures data integrity like check table i.e. foreign key relationship. Within SAP system there are three types of transaction and may be distinguished as:
     Database transaction known as LUW. It can be defined as a period in which operation requested must be performed as a unit, i.e. all or nothing operation. At the end of LUW, either of the database changes are committed or rolled back.
     Update transaction or SAP LUW. One SAP LUW can have several databases LUW. So a set of a database is either committed or rolled back. The special ABAP/4 command COMMIT WORK, marks the end of a SAP LUW.
     ABAP/4 transaction. Is made up of a set of related task combined under one transaction code. ABAP/4 transactions are for programming environment, in which ABAP/4 transaction functions like one complete object containing screens, menus and transaction codes.
R/3 system has provided in built locking mechanism, which defines the Logical Unit of Work. Also user can set his own locking mechanism. The LUW starts when a lock entry in the system table is created, and it ends when the lock is released.
To provide the user the facility to communicate with the table in order to modify or delete or insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to design screen, process screen through program and update the database table. SAP has provided one and only one way to update the database table, i.e. transaction. Though you can update database table by using open SQL statement through program, SAP usually doesnt recommend this kind of updating. Many standard transactions are available to update standard table but if the need arises, the developer should be able to develop new transaction, which allows the updating of database tables. This can be achieved by using various components of screen painter.
Following are the few concepts and steps for creating entire new transaction.
DYNPRO concept
A dynpro refers to the screen + flow logic. With screen painter you can develop screen and flow logic. The relationship between screen, flow logic, and program can be shown as follows:
Dynpro, as figure indicates consist of screen and flow logic and places exactly one call to module pool program. A transaction consists of many screens and for each screen flow logic is attached. When the transaction is executed, the screen places a call to flow logic and flow logic in turn places a call to module pool program.
     A module program is usual ABAP/4 program that consist of modules and data declaration.
     ABAP/4 is an event driven language. In module pool program too, events get triggered and these events are handled in flow logic. Flow logic editor is subset of ABAP/4 editor. The system automatically displays the two important events for the flow logic.
     Screen is the important component of dynpro and can be created, designed by screen painter.
Screen Painter
A screen painter can be started by
Development workbench  Screen Painter
Or
SE51 transaction code.
Using Screen Painter
The process of creating a dynpro includes the creation and definition of all the needed screen components.
The steps involved in creating the dynpro are as follows:
     Create screen and attributes by using screen attribute screen.
     Select and place the needed fields within the screen by using dict/program fields.
     Establish the field attributes to which the screen belongs by using field list.
     Define the flow logic respect to the transaction to which it belongs by using flow logic.
Creating a new Screen
Steps involved are as follows:
     Enter the name of program and number of the screen
     Click on Create
     On screen attribute screen enter short description
     Enter screen type. Normally, you select NORMAL option for usual R/3 screen. Other options available are SUBSCREEN & MODAL DIALOG BOX. Modal dialog box is used to establish independent and interactive dialog box while subscreen is screen within screen.
     Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen number, which must be processed after the current one.
Designing of Screen
Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen editor.
From screen attribute screen
By pressing full screen editor pushbutton
Or
From initial screen of screen painter.
There are two modes available with full screen editor.
     Graphical mode. The graphical mode works similarly to typical window application.
     Alphanumeric mode (rarely used).
Elements of screen
     Text Standard text or field labels.
     Entry - display field.
     Radiobutton All radiobutton must be associated with one group.
     Checkbox Normally used for YES/NO operations.
     Pushbutton Used for activating particular function.
     Boxes grouping together many screen elements.
     Subscreens This is a screen area in which you can display another screen.
     Table controls This area of screen is similar to table but should be treated as a loop.
     Status - Display output fields containing icon.
All these elements are on the control bar of full screen editor and can be placed on the screen work area by clicking and placing them wherever needed.
Selecting Screen Fields
Screen field can be either dictionary objects or program fields. Steps involved in the placing of fields on the screen are as follows:
Click the pushbutton Dict/program fields on the full screen editor
Or
Goto  dict/prog fields.
     Enter table name.
     Click Get from dictionary.
     Select fields.
     Click copy pushbutton.
     Position the cursor where you want those fields to be placed.
To adjust various screen elements, you can use drag and drop facility for screen elements.
Attributes of Screen Elements
The entire element of a screen has some attributes, which determines their behavior.
     General These attributes are directly managed by the screen painter like name of the element, or text of element or column width and various things associated with the screen.
     Dictionary These attributes are applicable to fields, which are from dictionary. Various components of dictionary can be attached to this element like search help, foreign key.
     Program.
     Display Behavior of the element with respect to their display feature.
Attribute dialog box can be displayed by
     Clicking on the ATTRIBUTE push button on the application tool bar.
     Double clicking on the element.
Field List
This list displays a list of all screen elements together with their screen attributes. One important element of Field list is OKCODE. Any pushbutton is associated with function code as in menu item in menu painter. When the user clicks the pushbutton this code is stored in OKCODE. This OKCODE is created by system without a name and is not visible on the screen. In ABAP/4 this field is work field and is nothing but an area wherein system stores the variable and is the last field of the field list and is invisible, hence user needs to give the name OKCODE. It is not mandatory to give the name OKCODE; developer can give any name to this field.
Screen Flow Logic
You can go to this screen either by
Initial screen of Screen painter  Flow logic
Or
From Screen attribute screen  Flow logic
When transaction is executed, the screen is displayed, user enters few fields, selects few functions. Later the screen is processed and processing of screen is done by flow logic.    The events that are associated with screen are as follows:
     Process before Output (PBO)
     Process after input (PAI)
     Process on value request (POV)
     Process on help request (POH)
The system automatically displays two very important events or modules in flow logic i.e. PAI and PBO
PBO event
This event is triggered before the screen is displayed. The processing of screen before the display of screen is done in this event. For example, filling in default values in the screen fields.
PAI event
This event is responsible for processing of screen after the user enters the data and clicks the pushbutton. The processing of screen can include displaying another screen, or just displaying list or quitting the transaction itself and many more things. Usually it is displaying another screen. These operations can be carried out in the PAI event. OKCODE plays an important role in this operation.
POV event
Process on value request is triggered when the user clicks F4 key. You can handle this event when the user presses F4 key by writing code for the same in module pool program. Normally when the user presses F4, list of possible values is displayed. The standard list produced by system is adequate for applications you develop yourself. However, you can also have the option of setting up your own documentation and lists of possible values that are more detailed.
POH event
Normally when the user places the cursor on the field and presses F1 function key, the system displays its own Help for that particular field. You can add your own functionality to the Help button by writing code for the same in the POH event.
Module Pool Programming
This component though is not attached to the screen painter, plays important role in transaction. Normally, for reports, on line executable programs are written but for transaction, Module Pool Programs are written. The module pool program contains only modules to handle various events associated with screen and data declaration statements.
System divides the module pool program into several include program. These are global field, PBO modules, and PAI modules. It is entirely users decision whether to use these modules or write directly into main program.
Creation of Module Pool Program
You can create module pool program either through
Object browser
System automatically creates the module pool program and for these program which are created through object browser, system creates the include modules.
Or
ABAP/4 editor
It is similar to normal program creation. Type of program should be given M and is not created by system.
Communication between Dynpro and Module Program
For each screen, the system executes the flow logic, which contains corresponding events. The control is passed to Module Pool Program. Module Pool Program handles the code for these events and again passes back control to the flow logic and finally to screen. Unlike on line program, in this case, the control remains with flow logic. The switching of control between flow logic and module pool program and back is common process when user executes transaction.
Creation of a Complete Transaction
Steps involved to create a complete transaction
     Create module pool program.
     From screen painter create screens.
     Write flow logic for each screen.
     Write code for all the events in module pool program.
     Check for any error in screen and flow logic.
     Generate each and every component of screen i.e. flow logic and screen.
     Single screen can be tested using Screen Painter.
     Create transaction code through object browser.
     Generate the transaction code.
     User can execute the transaction by entering the transaction code in the command field.
Handling Function Code
The function code or OKCODE is the last field of Field list. Function code can be handled as follows:
During the Designing of the screen, a function code is assigned to pushbutton.
     In field list, developer needs to specify OKCODE as last field.
     In module program it is a global field and can be evaluated in the PAI event.
     A function code is treated in the same way, regardless it comes from pushbutton, menu item or any other GUI element.
A complete example for transaction is shown below:
If you have a screen like the one below:
When the user clicks on the Display button, you want to display details of sflight, with corresponding carrid and connid (which is entered by the user).
Module pool program to handle this particular screen is as follows:
Program YVTEST7.
TABLES: SFLIGHT.
DATA: OKCODE (4).
MODULE INPUT1 INPUT,
CASE OKCODE.
   WHEN DISP.
     SELECT * FROM SFLIGHT
            WHERE CARRID = SFLIGHT CARRID AND
                           CONNID = SFLIGHT CONNID.
     ENDSELECT.
     LEAVE TO SCREEN 200.
   WHEN EXIT. LEAVE TO SCREEN 0.
ENDCASE.
ENDMODULE.               INPUT1 INPUT
MODULE USER_COMMAND_0200 INPUT.
CASE OKCODE.
WHEN BACK. LEAVE TO SCREEN 100.
ENDCASE.
ENDMODULE.                    USER_COMMAND_0200 INPUT
When the user clicks on display, control is transferred to screen no. 200 on which you display sflight details & on the same screen, when user clicks on BACK button, he comes back to main screen.
Flow logic for screen 100 is as follows:
PROCESS AFTER INPUT.
MODULE INPUT.
Flow logic for screen 200
PROCESS AFTER INPUT.
USER_COMMAND_0200.
MODULES: Modules are handled in module pool program.
You need to write flow logic for screen 200 and design screen 200.
In case of transaction transfer of data from program to screen is automatic i.e. you need not transfer the data from program to screen explicitly. The fields, which you define in the screen receives the data from program and displays the same.
The Field Checks
As already mentioned Transaction is the only method, which SAP recommends to update the database tables. Data entered in the database table should be valid and correct. Data entered is validated at each and every point. ABAP/4 offers various methods to validate data and those are as follows:
     Automatic field checks
     Checks performed in the flow logic
     Checks performed in the ABAP/4 module pool program
Automatic Field Checks
These checks are based on the field information stored in the dictionary. These checks are performed by the system automatically when the user enters the data for the screen field. System performs these checks before PAI event is triggered. Types of field checks performed by system are as follows:
     Required input
While designing the screen, for particular screen field if you click the Req. Entry checkbox, the field becomes mandatory. When the transaction is executed if user leaves this particular field blank, the system displays error message. User cannot proceed until the user enters some data.
     Proper Data Format
Each field has its own data format whether it is table field or screen field. Whenever data is entered, system checks for the proper format of the data. For example date. Each user has its own format for date, which is defined in the user master record. If the date defined in the user master record is in the format DD/MM/YYYY, if the user enters the date, say, in YY/DD/MM, the user displays the error message. System also checks for the value of month or days. For example if month entered is greater than twelve then the error message is displayed.
     Valid Value for the Field
In data dictionary two tables are related by Primary key-Foreign key relationship. Whenever the user enters the data, the system checks for the check table values.   Also in Domain, if you have fixed values, then the system checks for these values.
Automatic field checks are repeated each time the user enters the data.
About at Exit Command
Automatic field checks can be avoided by AT EXIT-COMMAND, which works exactly the same way as Cancel works on application tools bar. In the R/3 screen, if you want to quit the processing of that particular screen without entering the mandatory fields, user can click the Cancel button. Same functionality can be incorporated in the user-defined transaction by using AT EXIT-COMMAND. This module can be called before the system executes the automatic field checks and it goes without saying that before PAI event. Code for AT EXIT-COMMAND in flow logic and in module pool program can be written as follows:
In Flow Logic
Process After Input.
Module exit AT EXIT-COMMAND.
         In module pool program.
Module exit.
Case okcode.
When Exit.
Leave to screen 0.
To achieve this kind of functionality a pushbutton or menu item should be assigned a function type E. It tells the system to process this particular module before carrying out any field checks.
Flow Logic Validations
Consider the case where you want user to enter only LH and SQ for sflight-carrid. In this case, you are restricting value of a screen field. This cannot be achieved by automatic field check. Hence there is a need of additional validation. It can be done in flow logic by using following statement:
Field -
Values
Syntax
PAI.
Field sflight-carrid values (LH).
For multiple values
PAI.
Field sflight-carrid values (LH SQ).
Field sflight-price values (between 1000 and 2000).
In this case when the user enters the value, PAI is triggered and field is checked for that particular value. If the value entered happens to be wrong, that field is enabled for user to enter. If you have multiple Field statements in your flow logic, it is sequential execution.
Consider the following case:
PAI.
Module assign.
Field sflight-carrid values (LH SQ).
In ABAP/4
Module assign.
Data: carrid1 like sflight-carrid.
Carrid1 = sflight-carrid.
Endmodule.
In this case, Sflight-carrid is used in the flow logic before the field statement. The system will give invalid value or some previous value as the field sflight-carrid is used in module before it is checked i.e., field statement is after the module in which sflight-carrid is being used. The field is not available to the system unless it executes the field statement. Field statement transfers the values to the program and is done only once. If you dont have Field statement in your flow logic, transfer of values takes place in PAI event.
Consider one more case where you have multiple field statement.
PAI.
Field Sflight-carrid values (LH).
Field Sflight-connid values (0400 0500).
In this case if the user enters only carrid wrong, then this particular field is enabled and rest of the fields are disabled for user to input. Many times if the user enters wrong value for one field, then you might want to give option to user to enter all the fields, which is not possible by using Field statement only. This functionality can be achieved by CHAIN ENDCHAIN.
Syntax
Chain.
Field sflight-carrid value (LH).
     Field sflight-connid values (between 200 and 500).
Endchain.
Field sflight-price values (100 1000).
In this case, if the user enters wrong value only for carrid, both the fields i.e. carrid and connid are enabled as they are grouped together in the Chain statement. The field price will be disabled for input. Usually, logically related fields are grouped together with Chain-Endchain statement.
Module Pool Program Validations
Checking fields ABAP/4 program includes
     Field statement in flow logic.
     Module statement in ABAP/4 module pool Program.
Syntax
PAI.
Field sflight-carrid module <name>.
This module can be handled in the main program i.e. module pool program.
In ABAP/4 program
Module Check.
Select single * from sflight where carrid = sflight-carrid.
If sy-subrc ne 0.
     Message e001.
Endif.
In this case, field sflight-carrid is checked in the table for its existence.
Dynamically Calling the Screens
About Displaying Next Screen
Transaction is a sequence of screens, which are displayed one after the other. The next screen displayed depends upon the attributes of first screen. In attributes you need to give Next Screen number i.e. if next screen displayed should be 200 screen, then this number should be given in next Screen attributes. These are static attributes of the screen. By default, if nothing is specified in the program, the system branches out to the screen number, which is specified in the attribute screen.
But this doesnt happen always. If you have many pushbuttons on the screen like the one in the following case:
In this case, if user selects MARA pushbutton, then fields from Mara table are displayed. When the user clicks on the MARD, then the fields from MARD table are displayed. Depending upon users selection, the screen is branched out and this has to be done during runtime. This functionality can be achieved by dynamically calling the screen in module pool program.
The screen can branch out to new screen depending upon user selection. Following command in module pool program can do this:
     SET SCREEM
     CALL SCREEN
     LEAVE TO SCREEN <NUMBER>
All these commands override the specifications given in the attributes. This overriding is temporary. The values stored in the attribute are not changed.
Set Screen
Syntax
Set screen <number>.
In module pool program
Case okcode.
     When DISP.
          Set screen 200.
     When LIST.
          Set screen 300.
Endcase.
In this case, the entire processing of current screen takes place and then the system branches out to next screen. If you want to branch out to the next screen without processing the current screen, LEAVE SCREEN should be used along with the SET SCREEN.
For Example:
Case okcode..
     When DISP.
          Set screen 200.
          Leave Screen.
     When LIST.
          Set screen 300.
          Leave Screen.
Endcase.
When SET SCREEN is used, control cannot be transferred to the main screen or previous screen, unless you write code for the same.
Call Screen
Usually used for pop up screens. Many times, there is a need for user to enter additional information or secondary information on another screen or pop up screen. Once the user enters the data, he should be able to go back to main screen or to the screen where he started. This is not possible by using SET SCREEN. CALL SCREEN achieves this functionality.
Syntax
Call Screen 200.
Will simply call a screen number 200 from a main screen. Once the screen is displayed the user can enter all the data and return to the main screen by clicking BACK button.
To call screen as pop up screen the syntax is
Call screen starting at <col.no.> <line no>
                     Ending at <col no> <line no>.
In this case window will be popped as window and user can close it by using BACK button.
Leave to screen
To SET a new screen without processing current screen, you need to use the following two statements together:
SET SCREEN 200.
LEAVE SCREEN.
Or a Single statement
LEAVE TO SCREEN 200.
Subscreens
A subscreen is a screen within screen. Consider the following case.
If user clicks on FIRST pushbutton, you want to display details of MARA table and if user clicks on the SECOND pushbutton, you want to display details of MARD table. You can do this by calling two different screens. But the information will be displayed on the next screen. Displaying data on the same screen is possible by using SUBSCREENS.
Step to create a subscreen are as follows:
     Create a subscreen area on MAIN screen and name it.
     Create a separate screen of subscreen type.
     Arrange the fields on this screen so that they fit in subscreen area exactly. Only when it is larger, the part of the screen that fits in the main area will be visible.
     Write code for calling subscreen in flow logic.
To call subscreen, from your flow logic, you need to include the statement both in PAI and PBO.
Syntax
PBO.
Call subscreen <area> including <prg name> <screen no>.
PAI.
Call subscreen <area>.
Area - is the name of the area on main screen.
Prg. Name - is the name of the module pool program.
Screen number - is subscreen screen number.
Some of the donts with subscreen are:
GUI status cannot be set to the subscreen
     OKCODE is not applicable to the subscreen.
     Subscreen cannot call another screen.
     It cannot contain AT EXIT-COMMAND.
You can call multiple subscreen in the same area (at any given point of time, only one subscreen can be called in the subscreen area) and is done dynamically during runtime by using variable screen number.
Table Controls
A table can be created in transaction. These tables when designed on the screen are called as SCREEN TABLES. These screen tables are of two types viz.
     Table controls
     Step loops
Though these are tables when code is written to handle them, the tables are treated as loops.
Features of Table Controls
     Data is displayed in the form of table when many records match the criteria.
     Table control gives user the feeling of an actual table.
     You can scroll through the table vertically and horizontally.
     You can select rows and columns
     Resize the width of a column
     You can have separator lines in between rows and columns
     Automatic resizing of the table when the user resizes the window.
In general table control includes all the features of an actual table and user gets the feeling that he is actually working with table. You can update information in table control and it can be updated in the database table by writing code for it.
Steps associated for creating complete screen table are as follows:
     Declaration of table control in module pool program.
     Designing of table control on the screen.
     Passing data to table in flow logic.
Declaring of Table Control in the Module Pool Program
Syntax
Controls TCI type Tableview using screen <screen no.>
When you use table control in a screen you must declare the structure in module pool program. Important fields of tableview are as follows:
     Lines number of displayable rows in a table.
     Top_line the row of table where the screen displays start.
     Current_line The row currently being processed inside a loop.
When you process the table control in flow logic depending upon where you want to start display of rows, you need to use these variables.
Designing Table Control on Screen
     To design table control on the screen, you need to click on Table in control bar and place it on the screen. You can adjust the length and width of table control.
     Name the table control. (Here you need to use same name which you have used for declaration of table control in module pool program)
     From dictionary object, select table fields and place them in the table control.
Passing data to Table Control
As already mentioned, table controls are tables but are treated like loops. Usually transfer of data from program to screen is automatic. But in case of table control, transfer of data is not automatic. You need to explicitly transfer the data to table control. ABAP/4 provides loop statement, which is associated with flow logic to transfer the data. Because table control is treated like a loop, data from where it is transferred should be a loop. You cannot transfer the data by only select statement; you need to put the data into internal table. ABAP/4 provides the LOOP statement, which is associated with the flow logic and allows you to loop through the table control and internal tables. In between LOOP-ENDLOOP, you can use most of the flow logic keywords like field values. Module etc.
You need to code a LOOP statement in both PBO and PAI event of the screen. With LOOP statement, you can transfer the data from program to table control and vice versa. That is, if user updates the value in the table control, you can update database table with its value. And this can be done in PAI event. So even if you are not updating database table through the table control, you need to put the LOOP statement in the PAI event also.
Syntax
PBO.
LOOP AT <internal table> with control <table control name> cursor <scroll variable>
PAI.
Loop at itab.
Proper usage of Table Control is as follows:
In flow logic.
PBO.
LOOP AT ITAB WITH CONTROL TC1 CURSOR TC1-TOP_LINE.
MODULE ASSIGN.
ENDLOOP.
PAI.
LOOP AT ITAB.
ENDLOOP.
Considering, we have following fields in table control and the screen looks like this:
In module pool program
CONTROL TC1 Type tableview using screen 200.
Module assign.
Sflight carrid = itab carrid.
Sflight - connid= itab - connid.
Sflight - fldate= itab fldate.
Endmodule.
The transfer of the data from program to table control takes place in steps and these steps are as follows:
     With LOOP AT statement the first row is picked up and placed in the header of the internal table.
     Whatever statements you have in between LOOP-ENDLOOP are executed. In this case, you have Module statement. In Module statement, value of internal table is assigned to table control field.
     The row in internal table is transferred to the first line of the table control as stated in the LOOP AT statement.
     The system encounters the ENDLOOP statement and Control is passed to the next line of the internal table.
     In the same way, all the records of the internal table are passed to the table control.
STEP LOOPS
Step Loops are type of screen table as already mentioned. Step loops are repeated blocks of field in a screen. Each block contains one or more fields and these blocks are repeated. Step loops arent like actual table. You can scroll vertically but not horizontally. Three steps are associated with creation of step loops:
     Creation of step loops on screen, which includes declaring fields on the screen and then defining the step, loops for these fields.
     Passing data to the step loop is exactly similar to the passing of data to table controls.
     In step loop, you dont need to define the step loop as such in the module pool program but the cursor needs to be defined in the program.
Types of Step Loops
     Static Static Step Loop (SSL) have fixed size that cannot be changed during the runtime. If user resizes the window, the size of the static step loop is not changed.
     Dynamic Dynamic Step Loop (DSL) is variable in size. When the user resizes the window, the system increases or decreases the number of the step loop blocks.
You can have only one dynamic step loop and can have as many static loops in your    transaction.
Programming with the Static and dynamic step loop is exactly same. For the system or for the user it doesnt make any difference whether it is static or dynamic step loop. Only attribute, which you fix during designing of the step loop, is type attribute for step loop F for fixed i.e static and V for variable i.e. dynamic.
Writing code for Step Loop in the flow logic.
     PBO.
          Loop at itab cursor cl.
          Module set.
         Endloop.
     PAI.
          Loop at itab.
          Endloop.
Empty loop is must for both table control and step loop
LOOP AT statement for step loops and Table controls is similar. Loop At statement transfers the data to screen table. You need to have the Module to assign the values for the screen table.
In module pool program you need to define the cursor.
Date:   CL TYPE   i.
Cursor parameter tells which line of step loop display should start.
Module Set in module pool program assigns the values to step loop fields, which is similar to table controls.
Branching to List Processing
Switching To List Mode
You can display a list within a transaction.
You can produce a list from module pool program by using the command
Leave to List-Processing.
This statement switches the system from dialog mode to list mode. And from this point onwards until you return to dialog mode, you can use all the normal report statement like write, select or any other event.
Returning back from LIST mode
You can return back to dialog mode by clicking the BACK button.
You can have your GUI status and write code for the same. You can include the command LEAVE LIST-PROCESSING. When the system reaches this command, it leaves the list mode and returns to the dialog mode.
Help & Value Request
In any transaction, When the user presses F1 or ? on a field, System provides the help facility for that particular field. In dialog program, when F1 is pressed, help provided by R3 system is sourced from data element documentation. If this documentation is not present for that particular field or if user needs to display additional information for that particular field, then user defined help can be provided through PROCESS ON HELP REQUEST.
In ABVP/4 help can be provided to the user by:
Data element documentation: The F1 help can be enhanced, by adding an additional text for the data element in ABAP/4 dictionary.
It can be done with the help of following steps:
Place cursor on the screen field,
GOTO  DOCUMENTATION  DATA ELEMENT DOCUMENT
You can now extend the existing help.
USING THE PROCESS ON HELP-REQUEST.
If you dont have this event in a program, then the documentation of the field in the ABAP/4 dictionary is taken into consideration. If this event exits in the program then it is executed.
Process on HELP-REQUEST event
This event is triggered when user presses F1 on a screen field. You need to handle this event in flow-logic by specifying the fields and attaching the module to it.
Syntax
PROCESS ON HELP REQUEST.
FIELD SFLIGHT-CARRID MODULE HELP-FOR-CARRID.
In module pool program
MODULE HELP.
Write   : `This is field is from sflight table
Write   : / It is of four Character.
ENDMODULE.
When the user presses F1 on this particular field, then this message will be displayed on the screen.
Value Request
Whenever the user presses F4 on the screen field list of possible values, particular fields are displayed. If the standard value-help is inadequate or if you want to display additional fields or with different combination of fields, developer can program this in PROCESS ON VALUE-REQUEST event in the flow-logic and subsequent module in the module pool program. When the user presses F4, list of possible values are displayed either from matchcode objects or check table or help view or domain. Each one of them is explained briefly.
Matchcode objects: Are aggregated dictionary objects and detailed procedure to create these objects is explained in the later part of the material.
Check Table: If a check table is assigned to the table field and if the user presses F4 for that particular field, then all the key fields are displayed.
Domain Values: The values defined in the domain are displayed. These values are set in domain when the domain is created in the dictionary.
Help views: In cases where the check table is not sufficient, you can create a help view with this check table, which gives additional information like explanatory text for the fields of the check table.
PROCESS ON VALUE_REQUEST.
Each time the user presses F4 on the screen field, following algorithm is called internally.
When the user presses F4 on flight number, the following screen is displayed.
The screen displayed is pop-up screen and code for the flow logic and module is written below:
Flow-logic code

How to debug the abap program ?

how to debug the abap program ?Can anybody explain me in details.

Hi
Debugger
This section of the ABAP Workbench documentation provides information on how to use the Debugger as a test tool for finding errors in the source code of an ABAP program.
Functional Overview
Use
The ABAP Debugger is an integrated test tool within the ABAP Workbench. You use it to check the program logic and to find errors in the source code of an ABAP program. In the Debugger, you can step through the source code of a program. The running program is interrupted after each step, allowing you to check its processing logic and the results of individual statements.
As of Release 6.10, you can also run Business Server Pages (BSP) in the debugging mode. You can also display and set breakpoints here. Business Server Pages can be displayed in the Object Navigator when you select an appropriate application under BSP Application.
Features
The Debugger provides an efficient means of identifying errors in ABAP programs. It contains the following functions:
Ways of starting the Debugger
Choosing different views
Choosing different execution options in the Debugger
Displaying source code in the Debugger
Setting and deleting breakpoints
Setting and deleting watchpoints
Stopping a program at a particular statement or event
Displaying and changing field contents at runtime
Displaying ABAP Objects and references
Displaying and positioning strings
Setting and deleting database locks
Opening the ABAP Editor, or Object Navigator
System settings and runtime warnings
Starting the Debugger
There are two possible strategies for starting the Debugger in the ABAP Workbench:
By setting breakpoints then running the program
By running the program in debugging mode.
Setting Breakpoints
A breakpoint is a signal in a specific line of the program source code. This signal indicates to the ABAP runtime processor to stop the program at the relevant line and start the ABAP Debugger. A distinction is made between static and dynamic breakpoints. For further information about the different types of breakpoints and how to use them, refer to Breakpoints.
Direct Processing
You can start the Debugger without previously having set breakpoints. This is the best procedure to use when you want to test a program right from the beginning. It is also a useful procedure if you are not overly familiar with the program and therefore are not sure where best to set breakpoints. You can start the Debugger as follows:
From the Object Navigator
Select a report or transaction and choose Program ® Test ® Debugging.
From the ABAP Editor
Choose Program ® Execute ® Debugging (or the Debugging pushbutton).
From any screen
Choose System ® Utilities ® Debug ABAP.
From any screen
Enter /h in the command field.
Display Modes in the Debugger
When you are debugging a program, there are various display modes that you can use. All of the display modes have the same structure. The top part of the screen displays an extract of the program source code. The bottom part displays the information specifically available in that display mode. There are also pushbuttons on the screen allowing you to switch to the most frequently-used display modes.
Display Modes Available Using Pushbuttons
Fields
The scrollable field display contains the contents of up to eight fields. The contents of the three most important system fields are always displayed. This is the default display mode in the Debugger. See also Processing Fields
Table
Displays the contents of an internal table. This mode allows you to display and edit the entries in an internal table. See also Processing Internal Tables
Breakpoints
A scrollable display containing up to 30 breakpoints. Next to each breakpoint is a counter. You can also delete breakpoints in this display. See also Managing Dynamic Breakpoints
Watchpoints
You can set a watchpoint for a field so that the program is interrupted whenever the value of that field changes. This display mode contains a list of watchpoints, the fields and programs to which they are assigned, the current values of the fields, and the conditions upon which the watchpoint is activated. See also Setting Watchpoints
Calls
This mode displays the current sequence of events, and the sequence of calls up to the current breakpoint. The last active call is displayed at the top of the list; previous calls are listed in reverse chronological order. When an event (for example, START-OF-SELECTION) concludes, it is deleted from the display.
Overview
This mode displays the structure of the program. It lists its events, subroutines, and modules, and shows which sections belong to which events. It also displays the section currently being processed.
Settings
This mode displays the current Debugger settings. You can change the settings by selecting or deselecting various options. For further information, refer to Settings and Warnings
Other Display Modes
You can access other display modes by choosing Goto ® Display data object.
Single field
Displays the contents and technical attributes of a field.
Structured
field
Displays the components of a structure, along with their contents and attributes. If you double-click a component, the system displays detailed information for it.
Strings
Display the content and current length of the string. You can also display part of the content by means of offset and length.
Internal table
Displays the type, line numbers and contents of an internal table.
Object
Displays the structure of an ABAP Object.
For further information on these displays, refer to Displaying Attributes and Displaying ABAP Objects
Checking System Programs for Errors
To check a program or program component that is part of the ABAP Workbench (for example, the Screen Painter), you must use the system Debugger. To start the system Debugger, choose System ® Utilities ® Debug System from any screen. To stop the system Debugger, choose Debugger ® Debugging off.
Displaying Program Attributes
You can display the attributes Fixed Point Arithmetic, System Program, and Unicode Checks of the program that has just been executed by choosing Goto ® Further Information ® Program Attributes.
Restarting the Debugger
If you choose Debugging ® Restart, debugging mode is stopped and the system takes you to the initial screen of the last transaction you called. If, for example, you started an ABAP program in debugging mode from transaction SE38 (ABAP Editor), choosing Debugging ® Restart will take you back to the screen titled ABAP Editor: Initial Screen. If you want to restart the program in debugging mode, choose Debugging.
Breakpoints
Apart from direct execution of an ABAP program in the Debugger, it is also possible to start the Debugger call by the exact setting of a breakpoint. This is achieved by setting one or more of these breakpoints in the program. A breakpoint is a signal at a particular point in the program that tells the ABAP runtime processor to interrupt processing and start the Debugger. The program runs normally until the breakpoint is reached.
There is also a special kind of breakpoint called a watchpoint. When you use watchpoints, the Debugger is not activated until the contents of a particular field change. For further information, refer to Watchpoints.
Breakpoint Variants
The Debugger contains different breakpoint variants:
Static
The BREAK-POINT statement in an ABAP program. Static breakpoints are not normally user-specific. However, you can make them user-specific.
Directly-set
dynamic breakpoints
Can be set in the ABAP Editor or the Debugger. Dynamic breakpoints are always user-specific, and are deleted when you log off from the R/3 System.
Breakpoints
at statement
The Debugger stops the program directly before the specified statement is executed.
Breakpoints
at subroutine
The Debugger stops the program directly before the specified subroutine is called.
Breakpoint at function module
The Debugger stops the program directly before the specified function module is called.
Breakpoint at method
The Debugger stops the program directly before the specified method is called.
Breakpoints at system exceptions
The Debugger stops the program directly after a system exception, that is, after a runtime error has been intercepted.
Static Breakpoints
Static breakpoints are not normally user-specific. Once a user has inserted the statement BREAK-POINT or BREAK name in an ABAP program, the system always interrupts the program at that point for that user or only for the user name. This procedure is only useful in the development phase of an application, when the program execution is always to be interrupted at the same place. For further information, refer to Static Breakpoints.
In HTTP sessions, a static breakpoint is skipped if you did not set additional dynamic HTTP breakpoints in the editor of a BSP page. Instead, a corresponding system log entry is written, which can be checked using transaction SM21.
Dynamic Breakpoints
Dynamic breakpoints are user-specific. Therefore, you should use them if you only want the program to be interrupted when you run it yourself, not when it is being executed by other users. All dynamic breakpoints are deleted when you log off from the R/3 System.
Dynamic breakpoints are more flexible than static breakpoints, because you can deactivate or delete them at runtime. They have the following advantages:
You do not have to change the program code
You can set them even when the program is locked by another programmer
You can define a counter that only activates the breakpoint after it has been reached
Special dynamic breakpoints are useful when you want to interrupt a program directly before a particular ABAP statement, a subroutine, or an event, but do not know exactly where to find it in the source code. Event here is used to refer to the occurrence of a particular statement, for example, or calling up a method. Special dynamic breakpoints are user-specific. You can only set them in the Debugger. For further information, refer to Dynamic Breakpoints.
In HTTP sessions, the system stops both at static and dynamic breakpoints if a dynamic breakpoint was set in the editor of a BSP page before program execution.
Lifetime and Transfer of Breakpoints
A static breakpoint remains intact as long as the BREAK-POINT or BREAK-POINT name statement is not removed from the source code. Without saving, dynamic breakpoints only remain intact in the relevant internal session. However, they are effective during the entire user session, if they are saved by choosing Breakpoints ® Save in the ABAP Debugger. For more details on the subject of sessions and user sessions, refer to Modularization Techniques in the ABAP keyword documentation.
If you call an HTTP session during a user session, only the HTTP breakpoints are loaded when the HTTP session is started. You activate HTTP debugging in the ABAP Editor by choosing Utilities ® Settings ® HTTP Debugging. Depending on the setting, the system then displays either the HTTP or standard breakpoints in the Editor.
If you call an update session during a user session, breakpoints that were defined beforehand in the calling processing unit are copied to the new update session, where they can be displayed under Breakpoints. If, in the ABAP Debugger, you check Update Debugging under Settings and then, for example, call the update module func using CALL FUNCTION func IN UPDATE TASK, a new window is opened in which you can debug this function module in the update session. All the breakpoints that were set in the calling processing unit can also be processed here.
Breakpoints at Statements
You can use this special kind of dynamic breakpoint to interrupt a program directly before an ABAP statement is processed.
Prerequisites
You must already be running the program in the Debugger.
Procedure
To set a breakpoint at an ABAP statement:
1.Choose Breakpoint ® Breakpoint at ® Statement...
The following dialog box appears:
2.Enter the ABAP statement.
The system sets a breakpoint at all points in the program at which the ABAP statement occurs.
3.Choose ENTER.
The breakpoint applies to all lines containing the specified statement.
Result
The system confirms the breakpoint and adds it to the list in the display. When you finish your debugging session, the breakpoint is automatically deleted unless you have explicitly saved it.
Breakpoints at Subroutines
You can use this special kind of dynamic breakpoint to interrupt a program directly before a subroutine is called.
Prerequisites
You must already be running the program in the Debugger.
Procedure
To set a breakpoint for a subroutine:
Choose Breakpoint ® Breakpoint at ® Event/Subroutine.
The following dialog box then appears:
Enter the name of the subroutine before which you want to interrupt the program. By default, the Program field contains the name of the program that is currently active. The system sets a breakpoint wherever the specified subroutine occurs in the program code.
Choose ENTER.
Result
The system confirms the breakpoint. The breakpoint is added to the breakpoints displayed.
Breakpoints at Function Module
You can use this kind of dynamic breakpoint to interrupt a program directly before a function module is called.
Prerequisites
You must already be running the program in the Debugger.
Procedure
To set a breakpoint for a function module:
Choose Breakpoint ® Breakpoint at ® Function module...
The following dialog box appears:
Enter the name of the function module before which you want to interrupt the program. The system sets a breakpoint wherever the specified event, module pool, or subroutine occurs in the program code.
Choose ENTER.
Result
If you entered a valid function module name, the system confirms that the breakpoint has been set. If the function module exists in the system, the new breakpoint is added to the display list.
Breakpoints at Methods
You can use this special kind of dynamic breakpoint to interrupt a program directly before a method is called.
Prerequisites
You must be already running the program in the debugger.
Procedure
To set a breakpoint for methods:
1. Choose Breakpoint ® Breakpoint at ® Method...
The following dialog box then appears:
2. Enter the name of the method and class before which you want to interrupt the program. A breakpoint is then set each time the specified processing block appears in the source code.
3. Choose ENTER.
Result
The system confirms the breakpoint. The breakpoint is added to the list in the display.
Breakpoints at System Exceptions
You can use this special form of dynamic breakpoint to interrupt a program immediately after a runtime error has occurred.
Prerequisites
You must already be running the program in the Debugger.
Procedure
To set a breakpoint at a system exception:
Choose Breakpoint ® Breakpoint at ® System exception.
Result
The system confirms the breakpoint. The breakpoint is added to the breakpoints displayed.
When a system exception is triggered, a warning triangle appears in the line containing the statement that caused it. If you double-click the warning triangle, the internal name of the runtime error appears.
Static Breakpoints
You should only use static breakpoints during the development phase of an application. You must remove them from your program before you transport it.
Setting Breakpoints
To set a static breakpoint, use the ABAP statement BREAK-POINT . Place the breakpoint in the line at which you want to interrupt the program.
program RSDEBUG_01.
if SY-SUBRC 0.
break-point.
endif.
When you run the program, the runtime processor interrupts it when the breakpoints occur. You can number your breakpoints to make them easier to identify ( BREAK-POINT 1, BREAK-POINT 2 ).
Static breakpoints are not normally user-specific. The program is, therefore, always interrupted as soon as the runtime processor reaches the line containing the breakpoint. The program is interrupted regardless of the user who executes it.
However, you can set user-specific static breakpoints using the BREAK statement followed by your user name. For example, if you use the statement BREAK SMITH , the program is only interrupted when user Smith runs it. Although user-specific breakpoints appear in the program code, they are not active when other users run the program. You should, however, be careful if an application is being used by several users with the same name.
Deleting Breakpoints
Since static breakpoints apply to all users, you must remove them from the program once you have finished testing it. In the ABAP Editor, you can find breakpoints quickly by choosing Utilities ® Global search. You can also use the Extended Program Check to find them.
If you do not remove static breakpoints from your program, they will be transported to your production system. This could cause serious problems in the production system.
Dynamic Breakpoints
You can set up to 30 dynamic breakpoints without changing the program code. Dynamic breakpoints can be set either in the ABAP Editor or directly in the Debugger.
Setting Dynamic Breakpoints in the ABAP Editor
You can set dynamic breakpoints in the ABAP Editor regardless of whether you are in display or change mode. You can also set breakpoints directly from within the Debugger at runtime. To set a dynamic breakpoint in the ABAP Editor:
Position the cursor on the line of the source code at which you want to set the breakpoint.
Choose Utilities ® Breakpoints ® Set or the Stop icon. The system confirms that the breakpoint has been set.
To display a list of all dynamic breakpoints in a program, choose Utilities ® Breakpoints ® Display. You can use this list to navigate to a particular breakpoint or to delete one or more breakpoints from the program.
Setting Dynamic Breakpoints in Debugging Mode
To set a dynamic breakpoint in the Debugger:
Position the cursor on the line in which you want to set the breakpoint.
Select the line by double-clicking it or choosing Breakpoint ® Set/delete.
The system sets the breakpoint, and displays a small stop sign to the left of the relevant line. If the line already contained a breakpoint, it is deleted.
When you finish your debugging session, the breakpoint is automatically deleted unless you have explicitly saved it.
Saving Breakpoints
If you want to leave the Debugger temporarily, you can save your dynamic breakpoints so that they are still active when you return to the Debugger within the same terminal session.
To save the breakpoints that you have set in the Debugger:
Choose Breakpoint ® Save.
The system saves all of the breakpoints that you have set in the current program. These breakpoints will remain active until you either explicitly delete them or log off from the system.
You can also delete breakpoints that you have saved:
By deleting individual breakpoints from the display and then saving again. In this case, only your selected breakpoints will be deleted.
By choosing Breakpoint ® Delete all. In this case, the system deletes all dynamic breakpoints.
Managing Dynamic Breakpoints
The ABAP Debugger provides a convenient user interface for managing breakpoints. To open the breakpoint display, choose Breakpoints, or, from the menu, Goto ® Control debugging ® Breakpoints.
Example
Functions
This display mode contains the following functions for breakpoints:
Breakpoint Display
The scrollable breakpoint display contains up to 30 dynamic breakpoints. For breakpoints that you set directly, the program name and line number at which the breakpoint occurs are displayed. For special breakpoint forms, the list displays the statements, events, subroutines, and module calls at which the relevant breakpoints are set.
Counter
In the breakpoint display, you can specify a counter. When you use a counter, the breakpoint is not activated until it has been reached a specified number of times. For example, if you enter 5 for the counter, the breakpoint is not activated until it is reached for the fifth time. After the breakpoint has been activated, it remains so, and the counter no longer appears in the breakpoint display.
Deleting Breakpoints
Position the cursor on the breakpoint that you want to delete, and either double-click the line or choose Breakpoint ® Set/delete. To delete all breakpoints, choose Breakpoint ® Delete all.
Activating and Deactivating Breakpoints
Position the cursor on the breakpoint that you want to activate or deactivate and choose Breakpoint ® Activate/deactivate.
Watchpoints
Like a breakpoint, a watchpoint is an indicator in a program that tells the ABAP runtime processor to interrupt the program at a particular point. Unlike breakpoints, however, watchpoints are not activated until the contents of a specified field change. Watchpoints, like dynamic breakpoints, are user-specific, and so do not affect other users running the same program. You can only define watchpoints in the Debugger.
Use
You set watchpoints in the Debugger to monitor the contents of specific fields. They inform you when the value of a field changes. When the value changes, the Debugger interrupts the program.
Features
You can set up to five watchpoints in a program.
See also Setting Watchpoints.
You can also specify the conditions on which a watchpoint is to become active.
You can specify logical conditions between up to five conditional watchpoints.
See Specifying a Logical Expression.
You can define watchpoints as either local or global. If you define a global watchpoint, it is active in all called programs. Local watchpoints are only active in the specified program.
You can change and delete watchpoints.
See Changing Watchpoints.
You can use watchpoints to display changes to the references of strings, data and object references, and internal tables.
See Memory Monitoring with Watchpoints
Setting Watchpoints
If you want to interrupt a program when the contents of a field or structure change, use a watchpoint. You can set up to five watchpoints, including watchpoints for strings.
A watchpoint can be either local or global. Local watchpoints are only valid in the specified program. Global watchpoints are valid in the specified program, and also in all the other programs it calls.
Procedure
To set a watchpoint, start the Debugger and proceed as follows:
Choose Breakpoint ® Create watchpoint or the corresponding pushbutton. The Create Watchpoint dialog box appears:
Decide whether you want to set a local or global watchpoint.
Enter the program and the name of the field for which you want to set the watchpoint. In the Program field, the name of the program currently running is always defaulted.
If you want your watchpoint to be activated each time the contents of the field change, the definition is now complete, and you can return to the Debugger by pressing ENTER .
To create a conditional watchpoint, that is only activated when a particular situation arises, choose one of the following relational operators.
Operator
Meaning
<
Less than
<=
Less than or equal
=
Equal
<>
Not equal
=
Greater than or equal
Greater than
You can use the Comparison field option to specify whether the comparison is to be carried out with a value that you specify or with the contents of another field. Depending on your choice from step 6, enter a value or a field for the comparison.
Result
The system confirms the watchpoint and adds it to the list in the display. When you finish your debugging session, the watchpoint is automatically deleted unless you have explicitly saved it.
Specifying Logical Links
If you have more than one conditional watchpoint, you can specify a logical link between them:
OR
Only one of the specified conditions must be met
AND
All of the conditions must be met.
Changing Watchpoints
Choose Goto ® Control debugging ® Watchpoints or the Watchpoints pushbutton to display the watchpoint list. The following dialog box appears:
Choose the pencil icon in the line containing the watchpoint you want to change.
Change the watchpoint attributes in the Create/Change Watchpoint.
Choose ENTER .
Deleting Watchpoints
You cannot delete watchpoints by choosing Breakpoint ® Delete or Breakpoint ® Deactivate/activate. Instead, proceed as follows:
Choose Goto ® Control debugging ® Watchpoints or the Watchpoints pushbutton to display the watchpoint list.
Choose the trashcan icon in the line containing the watchpoint you want to delete.
Memory Monitoring with Watchpoints
You can use watchpoints to display changes to the references of strings, data and object references, and internal tables. By placing an ampersand (&) in front of the object name, you can display the reference in question in hexadecimal format. With internal tables, you can also display the table header by placing an asterisk (*) at the beginning of the name.
&objectname
Displays the references of strings, internal tables as well as data and object references
*itab
Displays the table header of the internal table itab
Example
If a watchpoint is set for the object in question at runtime, the program is stopped as soon as the reference is changed. A short dump can be intercepted in this way to stop the program being terminated when the memory is overwritten.
Analyzing Source Code
The Debugger contains an extensive range of functions that help you to analyze the source code of a program. You can step through the source code of a program in four different ways. For further information, refer to Stepping Through the Source Code
For information about functions within the source code display, see Displaying the Source Code
There are also different display modes that provide various information and display the contents of individual fields, tables, and so on:
Reward if usefull

Ways of debugging standard program

ways of debugging standard program to find out the solution!

Ways of starting the Debugger
Choosing different views
Choosing different execution options in the Debugger
Displaying source code in the Debugger
Setting and deleting breakpoints
Setting and deleting watchpoints
Stopping a program at a particular statement or event
Displaying and changing field contents at runtime
Displaying ABAP Objects and references
Displaying and positioning strings
Setting and deleting database locks
Opening the ABAP Editor, or Object Navigator
System settings and runtime warnings
Starting the Debugger
There are two possible strategies for starting the Debugger in the ABAP Workbench:
By setting breakpoints then running the program
By running the program in debugging mode.
Setting Breakpoints
A breakpoint is a signal in a specific line of the program source code. This signal indicates to the ABAP runtime processor to stop the program at the relevant line and start the ABAP Debugger. A distinction is made between static and dynamic breakpoints. For further information about the different types of breakpoints and how to use them, refer to Breakpoints.
Direct Processing
You can start the Debugger without previously having set breakpoints. This is the best procedure to use when you want to test a program right from the beginning. It is also a useful procedure if you are not overly familiar with the program and therefore are not sure where best to set breakpoints. You can start the Debugger as follows:
From the Object Navigator
Select a report or transaction and choose Program ® Test ® Debugging.
From the ABAP Editor
Choose Program ® Execute ® Debugging (or the Debugging pushbutton).
From any screen
Choose System ® Utilities ® Debug ABAP.
From any screen
Enter /h in the command field.
Display Modes in the Debugger
When you are debugging a program, there are various display modes that you can use. All of the display modes have the same structure. The top part of the screen displays an extract of the program source code. The bottom part displays the information specifically available in that display mode. There are also pushbuttons on the screen allowing you to switch to the most frequently-used display modes.
Display Modes Available Using Pushbuttons
Fields
The scrollable field display contains the contents of up to eight fields. The contents of the three most important system fields are always displayed. This is the default display mode in the Debugger. See also Processing Fields
Table
Displays the contents of an internal table. This mode allows you to display and edit the entries in an internal table. See also Processing Internal Tables
Breakpoints
A scrollable display containing up to 30 breakpoints. Next to each breakpoint is a counter. You can also delete breakpoints in this display. See also Managing Dynamic Breakpoints
Watchpoints
You can set a watchpoint for a field so that the program is interrupted whenever the value of that field changes. This display mode contains a list of watchpoints, the fields and programs to which they are assigned, the current values of the fields, and the conditions upon which the watchpoint is activated. See also Setting Watchpoints
Calls
This mode displays the current sequence of events, and the sequence of calls up to the current breakpoint. The last active call is displayed at the top of the list; previous calls are listed in reverse chronological order. When an event (for example, START-OF-SELECTION) concludes, it is deleted from the display.
Overview
This mode displays the structure of the program. It lists its events, subroutines, and modules, and shows which sections belong to which events. It also displays the section currently being processed.
Settings
This mode displays the current Debugger settings. You can change the settings by selecting or deselecting various options. For further information, refer to Settings and Warnings
Other Display Modes
You can access other display modes by choosing Goto ® Display data object.
Single field
Displays the contents and technical attributes of a field.
Structured
field
Displays the components of a structure, along with their contents and attributes. If you double-click a component, the system displays detailed information for it.
Strings
Display the content and current length of the string. You can also display part of the content by means of offset and length.
Internal table
Displays the type, line numbers and contents of an internal table.
Object
Displays the structure of an ABAP Object.
For further information on these displays, refer to Displaying Attributes and Displaying ABAP Objects
Checking System Programs for Errors
To check a program or program component that is part of the ABAP Workbench (for example, the Screen Painter), you must use the system Debugger. To start the system Debugger, choose System ® Utilities ® Debug System from any screen. To stop the system Debugger, choose Debugger ® Debugging off.
Displaying Program Attributes
You can display the attributes Fixed Point Arithmetic, System Program, and Unicode Checks of the program that has just been executed by choosing Goto ® Further Information ® Program Attributes.
Restarting the Debugger
If you choose Debugging ® Restart, debugging mode is stopped and the system takes you to the initial screen of the last transaction you called. If, for example, you started an ABAP program in debugging mode from transaction SE38 (ABAP Editor), choosing Debugging ® Restart will take you back to the screen titled ABAP Editor: Initial Screen. If you want to restart the program in debugging mode, choose Debugging.
Breakpoints
Apart from direct execution of an ABAP program in the Debugger, it is also possible to start the Debugger call by the exact setting of a breakpoint. This is achieved by setting one or more of these breakpoints in the program. A breakpoint is a signal at a particular point in the program that tells the ABAP runtime processor to interrupt processing and start the Debugger. The program runs normally until the breakpoint is reached.
There is also a special kind of breakpoint called a watchpoint. When you use watchpoints, the Debugger is not activated until the contents of a particular field change. For further information, refer to Watchpoints.
Breakpoint Variants
The Debugger contains different breakpoint variants:
Static
The BREAK-POINT statement in an ABAP program. Static breakpoints are not normally user-specific. However, you can make them user-specific.
Directly-set
dynamic breakpoints
Can be set in the ABAP Editor or the Debugger. Dynamic breakpoints are always user-specific, and are deleted when you log off from the R/3 System.
Breakpoints
at statement
The Debugger stops the program directly before the specified statement is executed.
Breakpoints
at subroutine
The Debugger stops the program directly before the specified subroutine is called.
Breakpoint at function module
The Debugger stops the program directly before the specified function module is called.
Breakpoint at method
The Debugger stops the program directly before the specified method is called.
Breakpoints at system exceptions
The Debugger stops the program directly after a system exception, that is, after a runtime error has been intercepted.
Static Breakpoints
Static breakpoints are not normally user-specific. Once a user has inserted the statement BREAK-POINT or BREAK name in an ABAP program, the system always interrupts the program at that point for that user or only for the user name. This procedure is only useful in the development phase of an application, when the program execution is always to be interrupted at the same place. For further information, refer to Static Breakpoints.
In HTTP sessions, a static breakpoint is skipped if you did not set additional dynamic HTTP breakpoints in the editor of a BSP page. Instead, a corresponding system log entry is written, which can be checked using transaction SM21.
Dynamic Breakpoints
Dynamic breakpoints are user-specific. Therefore, you should use them if you only want the program to be interrupted when you run it yourself, not when it is being executed by other users. All dynamic breakpoints are deleted when you log off from the R/3 System.
Dynamic breakpoints are more flexible than static breakpoints, because you can deactivate or delete them at runtime. They have the following advantages:
You do not have to change the program code
You can set them even when the program is locked by another programmer
You can define a counter that only activates the breakpoint after it has been reached
Special dynamic breakpoints are useful when you want to interrupt a program directly before a particular ABAP statement, a subroutine, or an event, but do not know exactly where to find it in the source code. Event here is used to refer to the occurrence of a particular statement, for example, or calling up a method. Special dynamic breakpoints are user-specific. You can only set them in the Debugger. For further information, refer to Dynamic Breakpoints.
In HTTP sessions, the system stops both at static and dynamic breakpoints if a dynamic breakpoint was set in the editor of a BSP page before program execution.
Lifetime and Transfer of Breakpoints
A static breakpoint remains intact as long as the BREAK-POINT or BREAK-POINT name statement is not removed from the source code. Without saving, dynamic breakpoints only remain intact in the relevant internal session. However, they are effective during the entire user session, if they are saved by choosing Breakpoints ® Save in the ABAP Debugger. For more details on the subject of sessions and user sessions, refer to Modularization Techniques in the ABAP keyword documentation.
If you call an HTTP session during a user session, only the HTTP breakpoints are loaded when the HTTP session is started. You activate HTTP debugging in the ABAP Editor by choosing Utilities ® Settings ® HTTP Debugging. Depending on the setting, the system then displays either the HTTP or standard breakpoints in the Editor.
If you call an update session during a user session, breakpoints that were defined beforehand in the calling processing unit are copied to the new update session, where they can be displayed under Breakpoints. If, in the ABAP Debugger, you check Update Debugging under Settings and then, for example, call the update module func using CALL FUNCTION func IN UPDATE TASK, a new window is opened in which you can debug this function module in the update session. All the breakpoints that were set in the calling processing unit can also be processed here.
Breakpoints at Statements
You can use this special kind of dynamic breakpoint to interrupt a program directly before an ABAP statement is processed.
Prerequisites
You must already be running the program in the Debugger.
Procedure
To set a breakpoint at an ABAP statement:
1.Choose Breakpoint ® Breakpoint at ® Statement...
The following dialog box appears:
2.Enter the ABAP statement.
The system sets a breakpoint at all points in the program at which the ABAP statement occurs.
3.Choose ENTER.
The breakpoint applies to all lines containing the specified statement.
Result
The system confirms the breakpoint and adds it to the list in the display. When you finish your debugging session, the breakpoint is automatically deleted unless you have explicitly saved it.
Breakpoints at Subroutines
You can use this special kind of dynamic breakpoint to interrupt a program directly before a subroutine is called.
Prerequisites
You must already be running the program in the Debugger.
Procedure
To set a breakpoint for a subroutine:
Choose Breakpoint ® Breakpoint at ® Event/Subroutine.
The following dialog box then appears:
Enter the name of the subroutine before which you want to interrupt the program. By default, the Program field contains the name of the program that is currently active. The system sets a breakpoint wherever the specified subroutine occurs in the program code.
Choose ENTER.
Result
The system confirms the breakpoint. The breakpoint is added to the breakpoints displayed.
Breakpoints at Function Module
You can use this kind of dynamic breakpoint to interrupt a program directly before a function module is called.
Prerequisites
You must already be running the program in the Debugger.
Procedure
To set a breakpoint for a function module:
Choose Breakpoint ® Breakpoint at ® Function module...
The following dialog box appears:
Enter the name of the function module before which you want to interrupt the program. The system sets a breakpoint wherever the specified event, module pool, or subroutine occurs in the program code.
Choose ENTER.
Result
If you entered a valid function module name, the system confirms that the breakpoint has been set. If the function module exists in the system, the new breakpoint is added to the display list.
Breakpoints at Methods
You can use this special kind of dynamic breakpoint to interrupt a program directly before a method is called.
Prerequisites
You must be already running the program in the debugger.
Procedure
To set a breakpoint for methods:
1. Choose Breakpoint ® Breakpoint at ® Method...
The following dialog box then appears:
2. Enter the name of the method and class before which you want to interrupt the program. A breakpoint is then set each time the specified processing block appears in the source code.
3. Choose ENTER.
Result
The system confirms the breakpoint. The breakpoint is added to the list in the display.
Breakpoints at System Exceptions
You can use this special form of dynamic breakpoint to interrupt a program immediately after a runtime error has occurred.
Prerequisites
You must already be running the program in the Debugger.
Procedure
To set a breakpoint at a system exception:
Choose Breakpoint ® Breakpoint at ® System exception.
Result
The system confirms the breakpoint. The breakpoint is added to the breakpoints displayed.
When a system exception is triggered, a warning triangle appears in the line containing the statement that caused it. If you double-click the warning triangle, the internal name of the runtime error appears.
Static Breakpoints
You should only use static breakpoints during the development phase of an application. You must remove them from your program before you transport it.
Setting Breakpoints
To set a static breakpoint, use the ABAP statement BREAK-POINT . Place the breakpoint in the line at which you want to interrupt the program.
program RSDEBUG_01.
if SY-SUBRC 0.
break-point.
endif.
When you run the program, the runtime processor interrupts it when the breakpoints occur. You can number your breakpoints to make them easier to identify ( BREAK-POINT 1, BREAK-POINT 2 ).
Static breakpoints are not normally user-specific. The program is, therefore, always interrupted as soon as the runtime processor reaches the line containing the breakpoint. The program is interrupted regardless of the user who executes it.
However, you can set user-specific static breakpoints using the BREAK statement followed by your user name. For example, if you use the statement BREAK SMITH , the program is only interrupted when user Smith runs it. Although user-specific breakpoints appear in the program code, they are not active when other users run the program. You should, however, be careful if an application is being used by several users with the same name.
Deleting Breakpoints
Since static breakpoints apply to all users, you must remove them from the program once you have finished testing it. In the ABAP Editor, you can find breakpoints quickly by choosing Utilities ® Global search. You can also use the Extended Program Check to find them.
If you do not remove static breakpoints from your program, they will be transported to your production system. This could cause serious problems in the production system.
Dynamic Breakpoints
You can set up to 30 dynamic breakpoints without changing the program code. Dynamic breakpoints can be set either in the ABAP Editor or directly in the Debugger.
Setting Dynamic Breakpoints in the ABAP Editor
You can set dynamic breakpoints in the ABAP Editor regardless of whether you are in display or change mode. You can also set breakpoints directly from within the Debugger at runtime. To set a dynamic breakpoint in the ABAP Editor:
Position the cursor on the line of the source code at which you want to set the breakpoint.
Choose Utilities ® Breakpoints ® Set or the Stop icon. The system confirms that the breakpoint has been set.
To display a list of all dynamic breakpoints in a program, choose Utilities ® Breakpoints ® Display. You can use this list to navigate to a particular breakpoint or to delete one or more breakpoints from the program.
Setting Dynamic Breakpoints in Debugging Mode
To set a dynamic breakpoint in the Debugger:
Position the cursor on the line in which you want to set the breakpoint.
Select the line by double-clicking it or choosing Breakpoint ® Set/delete.
The system sets the breakpoint, and displays a small stop sign to the left of the relevant line. If the line already contained a breakpoint, it is deleted.
When you finish your debugging session, the breakpoint is automatically deleted unless you have explicitly saved it.
Saving Breakpoints
If you want to leave the Debugger temporarily, you can save your dynamic breakpoints so that they are still active when you return to the Debugger within the same terminal session.
To save the breakpoints that you have set in the Debugger:
Choose Breakpoint ® Save.
The system saves all of the breakpoints that you have set in the current program. These breakpoints will remain active until you either explicitly delete them or log off from the system.
You can also delete breakpoints that you have saved:
By deleting individual breakpoints from the display and then saving again. In this case, only your selected breakpoints will be deleted.
By choosing Breakpoint ® Delete all. In this case, the system deletes all dynamic breakpoints.
Managing Dynamic Breakpoints
The ABAP Debugger provides a convenient user interface for managing breakpoints. To open the breakpoint display, choose Breakpoints, or, from the menu, Goto ® Control debugging ® Breakpoints.
Example
Functions
This display mode contains the following functions for breakpoints:
Breakpoint Display
The scrollable breakpoint display contains up to 30 dynamic breakpoints. For breakpoints that you set directly, the program name and line number at which the breakpoint occurs are displayed. For special breakpoint forms, the list displays the statements, events, subroutines, and module calls at which the relevant breakpoints are set.
Counter
In the breakpoint display, you can specify a counter. When you use a counter, the breakpoint is not activated until it has been reached a specified number of times. For example, if you enter 5 for the counter, the breakpoint is not activated until it is reached for the fifth time. After the breakpoint has been activated, it remains so, and the counter no longer appears in the breakpoint display.
Deleting Breakpoints
Position the cursor on the breakpoint that you want to delete, and either double-click the line or choose Breakpoint ® Set/delete. To delete all breakpoints, choose Breakpoint ® Delete all.
Activating and Deactivating Breakpoints
Position the cursor on the breakpoint that you want to activate or deactivate and choose Breakpoint ® Activate/deactivate.
Watchpoints
Like a breakpoint, a watchpoint is an indicator in a program that tells the ABAP runtime processor to interrupt the program at a particular point. Unlike breakpoints, however, watchpoints are not activated until the contents of a specified field change. Watchpoints, like dynamic breakpoints, are user-specific, and so do not affect other users running the same program. You can only define watchpoints in the Debugger.
Use
You set watchpoints in the Debugger to monitor the contents of specific fields. They inform you when the value of a field changes. When the value changes, the Debugger interrupts the program.
Features
You can set up to five watchpoints in a program.
See also Setting Watchpoints.
You can also specify the conditions on which a watchpoint is to become active.
You can specify logical conditions between up to five conditional watchpoints.
See Specifying a Logical Expression.
You can define watchpoints as either local or global. If you define a global watchpoint, it is active in all called programs. Local watchpoints are only active in the specified program.
You can change and delete watchpoints.
See Changing Watchpoints.
You can use watchpoints to display changes to the references of strings, data and object references, and internal tables.
See Memory Monitoring with Watchpoints
Setting Watchpoints
If you want to interrupt a program when the contents of a field or structure change, use a watchpoint. You can set up to five watchpoints, including watchpoints for strings.
A watchpoint can be either local or global. Local watchpoints are only valid in the specified program. Global watchpoints are valid in the specified program, and also in all the other programs it calls.
Procedure
To set a watchpoint, start the Debugger and proceed as follows:
Choose Breakpoint ® Create watchpoint or the corresponding pushbutton. The Create Watchpoint dialog box appears:
Decide whether you want to set a local or global watchpoint.
Enter the program and the name of the field for which you want to set the watchpoint. In the Program field, the name of the program currently running is always defaulted.
If you want your watchpoint to be activated each time the contents of the field change, the definition is now complete, and you can return to the Debugger by pressing ENTER .
To create a conditional watchpoint, that is only activated when a particular situation arises, choose one of the following relational operators.
Operator
Meaning
<
Less than
<=
Less than or equal
=
Equal
<>
Not equal
=
Greater than or equal
Greater than
You can use the Comparison field option to specify whether the comparison is to be carried out with a value that you specify or with the contents of another field. Depending on your choice from step 6, enter a value or a field for the comparison.
Result
The system confirms the watchpoint and adds it to the list in the display. When you finish your debugging session, the watchpoint is automatically deleted unless you have explicitly saved it.
Specifying Logical Links
If you have more than one conditional watchpoint, you can specify a logical link between them:
OR
Only one of the specified conditions must be met
AND
All of the conditions must be met.
Changing Watchpoints
Choose Goto ® Control debugging ® Watchpoints or the Watchpoints pushbutton to display the watchpoint list. The following dialog box appears:
Choose the pencil icon in the line containing the watchpoint you want to change.
Change the watchpoint attributes in the Create/Change Watchpoint.
Choose ENTER .
Deleting Watchpoints
You cannot delete watchpoints by choosing Breakpoint ® Delete or Breakpoint ® Deactivate/activate. Instead, proceed as follows:
Choose Goto ® Control debugging ® Watchpoints or the Watchpoints pushbutton to display the watchpoint list.
Choose the trashcan icon in the line containing the watchpoint you want to delete.
Memory Monitoring with Watchpoints
You can use watchpoints to display changes to the references of strings, data and object references, and internal tables. By placing an ampersand (&) in front of the object name, you can display the reference in question in hexadecimal format. With internal tables, you can also display the table header by placing an asterisk (*) at the beginning of the name.
&objectname
Displays the references of strings, internal tables as well as data and object references
*itab
Displays the table header of the internal table itab
Example
If a watchpoint is set for the object in question at runtime, the program is stopped as soon as the reference is changed. A short dump can be intercepted in this way to stop the program being terminated when the memory is overwritten.
Analyzing Source Code
The Debugger contains an extensive range of functions that help you to analyze the source code of a program. You can step through the source code of a program in four different ways. For further information, refer to Stepping Through the Source Code
For information about functions within the source code display, see Displaying the Source Code
There are also different display modes that provide various information and display the contents of individual fields, tables, and so on:
Reward if usefull

How to Spawn a concurrent program from another Concurrent Program

Hi,
I need to write a concurrent program with PL/sql procedure. Inside this procedure, for a cursor data, for each record I need to spawn another concurrent program. How can I do this. Should I call a concurrent program using fnd_request.submit_request?
Any suggestions?
Thanks,
HC

Correct - you will need to use FND_REQUEST. Pl use the search feature of these forums to find old threads that discuss this topic
https://forums.oracle.com/forums/search.jspa?threadID=&q=FND_REQUEST+AND+SUBMIT_REQUEST&objID=c3&dateRange=all&userID=&numResults=15
How To Submit A Concurrent Request Set Using Fnd_Request.Submit_Request [Document 382791.1]
Most Commonly Used FND APIs in APPS Customizations [Document 221549.1]
HTH
Srini

Programming NAME_ADDR component in procedure

Similar Messages

Maybe you are looking for