STATEMENTS In SAP ABAP:
Use CLEAR to reset any variable data object to the initial value appropriate to its type .
In a structure, each component is reset individually.
In an internal table without a header line, all of the lines are deleted.
Use MOVE to copy the contents of one data object to another variable data object.
With complex objects, you can either address the components individually or use a "deep copy". If the source and target objects are compatible (see next page), the system copies the objects component by component or line by line.
If they are not compatible, the system converts the objects as long as there is an appropriate conversion rule.
If you are copying between two structures, and only want to copy values between identically-named fields, you can use the MOVE-CORRESPONDING statement.
The conversion mechanisms explained on the following pages apply not only to the MOVE and MOVECORRESPONDING statements, but also to calculations and value comparisons.
Unlike the MOVE statement, when you use WRITE... TO... to assign values, the target field is always regarded as a character field, irrespective of its actual type. WRITE...TO behaves in the same way as when you write output to a list. This allows
you to use formatting options when you copy data objects (for example, country-specific date formatting).
If two data types are not compatible but there is a converion rule, the system converts the source object into the type of the target object when you assign values, perform calculations, or compare values.
The following pages contain the basic forms of the conversion rules, and examples for the most frequent cases. For a full list of all conversion rules, refer to the ABAP syntax documentation for the MOVE statement.
If there is no conversion rule defined for a particular assignment, the way in which the system reacts depends on the context in which you programmed the assignment.
If the types of the objects involved are defined statically, a syntax error occurs.
Example:
DATA: date TYPE d VALUE '19991231', time TYPE t.
FIELD-SYMBOLS: TYPE d, TYPE t.
ASSIGN: date TO , time TO .
= .
If the types of the objects involved are defined dynamically, a runtime error occurs, because the system cannot tell in the syntax check whether they are convertible or not.
Example (remainder as above):
FIELD-SYMBOLS: TYPE ANY, TYPE ANY.
In general, there is a rule for converting every predefined ABAP data type into any other predefined type.
Special cases:
There are no rules for converting from type D to type T or vice versa, or for converting ABAP Objects data types (object reference to obje ct reference, object reference to interface reference). Assignments or comparisons of this type cause syntax errors (where it is possible for the system to detect them).
When you assign a type C field to a type P field, you may only use digits, spaces, a decimal point, and a plus or minus sign. The target field must also be large enough.
When you convert a packed number to a type C field, the leading zeros are converted into spaces. For full information about conversion rules for elementary types, refer to the online documentation in the ABAP Editor for the MOVE statement.
The ABAP runtime environment has rules for converting
Structures to non-compatible structures
Elementary fields to structures
Structures to elementary fields
In each case, the system converts the source variables to character fields and fills the target structures byte by byte. The relevant conversion rules for elementary fields then apply.
Internal tables can only be converted into other internal tables. The system converts the lines types according to the relevant rule for structures.
The example above shows that copying between non-compatible types may result in the target fields containing values that cannot be interpreted properly. To avoid this problem, you should copy values field by field in these cases. This ensures that the system applies the correct conversion rule for elementary fields.
If you want to manipulate strings, it is better to use the statements expressly intended for this purpose. You can use the following statements to process strings in ABAP:
SEARCH To search in a string
REPLACE To replace the first occurrence of a string
TRANSLATE To replace all specified characters
SHIFT To shift a character at a time
CONDENSE To remove spaces
CONCATENATE To chain two or more strings together
OVERLAY To overlay two strings
SPLIT To split a string
In all string operations, the operands are treated like type C fields, regardless of their actual field type. They are not converted.
All of the statements apart from TRANSLATE and CONDENSE set the system field sy-subrc. SEARCH also sets the system field sy-fdpos with the offset of the beginning of the string found.
All of the statements apart from SEARCH distinguish between upper- and lowercase.
To find out the occupied length of a string, use the standard function STRLEN().
The system searches the field for the string . The search string can have the following form:
'' String (trailing blanks are ignored)
'..' Any string between the periods (spaces are included in the search.)
'*' A string beginning with and including ''
'*' A string beginning with and including ''
The offset of the found string is placed in the system field sy-fdpos If the search string is not found, sy-fdpos contains the value 0 and sy-subrc is set to 4.
You can use SEARCH instead of SEARCH . The system then searches for the search string within the internal table . In this variant, the
system also sets the system field sy-tabix to the index of the line containing the search string.
REPLACE WITH INTO .
Replaces the first occurrence of in with .
TRANSLATE USING .
Replaces all letters in according to . contains the search and replacement characters in pairs. For the example: TRANSLATE ... USING 'AB'.
TRANSLATE TO UPPER|LOWER CASE
Replaces all lowercase letters in with uppercase (or vice versa).
SHIFT [] [RIGHT] [CIRCULAR].
can be one of the following:
BY PLACES Shifts by characters
UP TO Shifts up to the beginning of
The additions have the following effect:
RIGHT Shifts to the right
CIRCULAR Shifts to the right - characters shifted off the right-hand edge of the field reappear on the left.
CONDENSE [NO-GAPS].
Consecutive spaces are replaced by a single space or are deleted.
Note:
You can delete leading or trailing spaces using
SHIFT LEFT DELETING LEADING SPACE or
SHIFT RIGHT DELETING TRAILING SPACE.
SPLIT AT INTO ... |TABLE }.
Splits at each occurrence of the separator string and places the parts into the fields .... or into consecutive lines of the internal table .
CONCATENATE ... INTO [SEPARATED BY ].
Combines the fields ... in . Trailing spaces are ignored in the component fields. You can use the SEPARATED BY addition to insert the string between the strings ... .
OVERLAY WITH [ONLY ].
overlays at all positions where contains a space or one of the characters in .
Note
See also Accessing Parts of Fields.
In any statement that operates on a character-type field, you can address part of the field or structure by specifying a starting posit ion and a number of characters. If the field lengths are different, the system either truncates the target or fills it with initial values. The source and target fields must have the type X, C, N, D, T, or STRING. You can also use structures.
Example MOVE +() TO +().
This statements assigns characters of field starting at offset to characters of starting at offset .
Caution
Under Unicode *) only fields with type C, X, and STRING are suitable for partial access. In other cases, you should use field symbols with casting.
Language- and culture-independent character set.
In ABAP, you can program arithmetic expressions nested to any depth. You must remember that parentheses and operators are keywords, and must therefore be preceded and followed by at least one space.
The ABAP runtime environment contains a range of functions for different data types. The opening parenthesis belongs to the functions name itself (and is therefore not separated from it by a space).
The remaining elements of each expression must be separated by spaces.
The expressions are processed in normal algebraic sequence - parenthetical expressions, followed by functions, powers, multiplication and division, and finally, addition and subtraction. A calculation may contain any data types that are convertible into each other and into the type of the result field. The system converts all of the fields into one of the three numeric data types (I, P, or F), depending on the data types of the operands. The ABAP runtime system contains an arithmetic for each of the three data types. The system then performs the calculation and converts it into the data type of the result field.
The DIV (integer division) and MOD (remainder of a division) always return whole numbers. In integer and packed number arithmetic, the system always rounds to the corresponding decimal place. So, for example:
DATA int TYPE i. int = 4 / 10. " result: 0
int = 5 / 10. " result: 1
or DATA: pack TYPE p DECIMALS 2. pack = 4 / 1000. " result: 0.00 pack = 5 / 1000. " result: 0.01.
However, intermediate results using packed numbers are always accurate to 31 decimal places. The arithmetic used depends on how the system interprets the numeric literals:
DATA int TYPE i. int = 1000000000 / 300000000 * 3. " result: 9
int = 10000000000 / 3000000000 * 3. " result: 10
If you do not set the fixed point arithmetic option in the program attributes, the DECIMALS addition in the DATA statement only affects the output, not the arithmetic. In this case, all numbers are interpreted internally as integers, regardless of the position of the decimal point. You would then have to calculate the number of decimal places manually and ensure that the number was displayed correctly. Otherwise, the results would be meaningless.
DATA: pack TYPE p DECIMALS 2.
pack = '5000.00' * '0.20'. " result: pack = 100000.00
Furthermore, the system would also round internally (integer arithmetic - see above).
The fixed point arithmetic option is always selected by default. You should always accept this value and use packed numbers for business calculations.
Calculations using data type F are always, for technical reasons, imprecise.
Example Suppose you want to calculate 7.72% of 73050 and display the result accurate to two decimal places. The answer should be 5310.74 (73050 * 0.0727 = 5310.735).
However, the program returns the following:
DATA: float TYPE f, pack TYPE p DECIMALS 2.
float = 73050 * '0.0727'. " result: 5.3107349999999997E+03
pack = float. WRITE pack. " result: 5310.73
You should therefore only use floating point numbe rs for approximations. When you compare numbers, always used intervals, and always round at the end of your calculations.
There are four general categories of runtime error that can occur in calculations:
A field that should have been converted could not be interpreted as a number.
A number range is too small for a conversion, value assignment, or to store intermediate results.
You tried to divide by zero.
You passed an invalid argument to a built-in function
(For example: ... log( -3 ) ... ).
For further information, refer to the ABAP syntax documentation for the COMPUTE statement.
If you assign a date fields to a numeric field, the runtime system calculates the number of days that have elapsed since 01.01.0001.
Conversely, when you assign a numeric value to a date field, the system interprets it as the number of days since 01.01.0001.
Before any calculations are performed with dates, the value of the date field is converted into its numeric value (number of days since 01.01.0001)
The above example calculates the last day of the previous month.
When you calculate with time fields, the system uses a similar procedure, that is, it counts the number of seconds since 0:00:00.
Comparisons between non-numeric data objects are interpreted differently according to their data type.
If possible: Conversion into numbers (heaxadecimal, for example, as dual number);
Date and time: Interpreted as earlier/later, so 31.12.1999 < f1 =" f2" f3 =" f4" f5 =" f6" f1 =" f2" f3 =" f4" f5 =" f6"> .. can contain an operator as follows:
CO only contains characters from ;
CN contains not only characters from (corresponds to NOT CO );
CA contains at least one character from ;
NA does not contain any characters from ;
CS contains the string ;
NS does not contain the string ;
CP contains the pattern ;
NP does not contain the pattern ;
The system field sy-fdpos contains the offset of the character that satisfies the condition, or the length of .
In the first four expressions, the system takes into account upper- and lowercase letters and the full length of the string (SPACE column).
To specify patterns, use '*' for any string, and '+' for any character. The escape symbol is '#'.
In a CASE - ENDCASE structure, you test a data object for equality against various values. When a test succeeds, the corresponding statement block is executed. If all of the comparisons fail, the OTHERS block is executed, if you have programmed one.
In an IF - ENDIF structure, you can use any logical expressions. If the condition is met, the corresponding statements are executed. If none of the conditions is true, the ELSE block is executed, if you have programmed one.
In both cases, the system only executes one statement block, namely that belonging to the first valid case.
If each condition tests the same data object for equality with another object, you should use a CASEENDCASE structure. It is simpler, and requires less runtime .
Outside a loop, you can make the execution of all remaining statements in the current processing block conditional using CHECK. If the check fails, processing resumes with the first statement in the next processing block.
There are four loop structures. The number of the current loop pass is always available from the system field sy-index. If you use nested loops, the value of sy-index refers to the current one. You can take control over loop processing using the CHECK and EXIT statements. For further information, refer to Leaving Processing Blocks. The graphic shows how you can control the further processing of a loop.
Unconditional/Index-based loops
The statements between DO and ENDDO are executed until you end the loop with a termination statement. You can specify a maximum number of loop passes. If you do not, you have an endless loop.
Conditional loops
The statements beween WHILE and ENDWHILE are repeated as long as the condition is met.
Multiple -line access to an internal table
For further information, refer to the Internal Table Operations unit.
Multiple -record access to a database table or view
Reminder
A processing block is an ABAP event block or modulariziation unit.
You can use the ABAP statement CHECK outside a loop to terminate the processing block if the logical condition is not met. Processing continues with the first statement in the next processing block. Within a loop, processing resumes at the beginning of the next loop pass.
The EXIT statement can behave in three different ways: Within a loop, it terminates the loop processing completely. Outside a loop but in one of the events listed under Events I, it makes the system display the current contents of the list buffer. Events from the other groups listed above can still be triggered. In the case of LOAD-OF-PROGRAM, START-OF-SELECTION is triggered.
In all other cases, EXIT has the same effect as CHECK.
The statements LEAVE PROGRAM and LEAVE TO TRANSACTION terminate the current program.
When you send a termination (type A) message, the current program ends, and the entire program stack is destroyed. For further information, refer to the unit Program Calls and Passing Data.
Within a processing block, you can use the structure CATCH SYSTEM-EXCEPTIONS...
ENDCATCH to catch runtime errors. If the specified system exception occurs, the system leaves the Statements in the block and continues processing after the ENDCATCH statement. This construction only catches runtime errors at the current call level.
If you call a subroutine in which a runtime error is triggered, you must catch this error in the subroutine itself.
Each runtime error is assigned to an ERROR class. For a full list, refer to the syntax documentation for the CATCH statement.
You can specify one of the following as the system exception that you want to catch:
A single error (for example, convt_no_number);
ERROR classes (for example, arithmetic_errors);
All catchable runtime errors.
The return code values ... must be numeric literals.
The return code assigned to the runtime error that occurred is placed in the system field sy-subrc. If more than one value was assigned to it, the system uses the first. This is particularly important if you specify two different ERROR classes that contain the same runtime error.
CATCH SYSTEM-EXCEPTIONS ... ENDCATCH constructions can be nested to any depth. If a runtime error occurs, the system searches for an assignment in the current statement block. If it does not find one, it searches in the next-highest block, and so on. Processing resumes after the ENDCATCH statement of the block in which the assignment was found.
The above example nests three CATCH SYSTEM-EXCEPTIONS ... ENDCATCH structures.
Before each ENDCATCH statement is a statement that causes a runtime error.
At which statement does the system set the field sy-subrc? With which value? At which statement does processing resume?
The division by zero in the innermost block triggers the runtime error bcd_zerodivide. However, there is no assignment for the error in this block.
Consequently, the system looks in the next-highest block for the error, where it is assigned. sy-subrc is set to 4.
The system resumes processing at the first statement after the middle ENDCATCH statement. The assignment of a string (which cannot be interpreted as a packed number) to a packed number field is therefore not executed, even though we would have caught the ensuing runtime error convt_no_number in our program.
Finally, we trigger the runtime error convt_overflow by assigning a number to the packed field that is too big for it. A return code is assigned to this error in the outer block.
sy-subrc is set to 2.
The system resumes processing after the corresponding ENDCATCH statement.
Saturday, October 11, 2008
Subscribe to:
Post Comments (Atom)
Archives
-
▼
2008
(167)
-
▼
October
(145)
- SAP ALE ABAP DETIAL
- SAP ABAP ALE IDOC'S
- SAP - DIFFERENCE BETWEEN CONVERSION AND INTERFACE
- BAPI AND IDOC ALE
- SAP ABAP MESSAGE CONTORL
- SAP IDOC'S IN ABAP INTRODUCTION
- SAP ABAP IDOC'S OUTLOOK
- SAP ABAP IDOC PROCESSING
- SAP ABAP IDOC'S BASIC TOOLS I
- SAP ABAP IDOC'S BASIC TOOLS II
- SAP ABAP IDOC'S INBOUND BASIC TOOLS III
- SAP IDOC OUT BOUND TRIGGERS II
- SAP IDOCS OUTBOUND TRIGGER II
- SAP IDOC'S OUTBOUND TRIGGER III
- SAP Work flow based outbound Idoc's
- SAP ALE Change Pointers
- SAP Dispatching ALE IDocs for Change Pointers
- SAP IDOC design and Processing
- SAP Creation of the IDoc Data
- SAP Developing an Outbound IDoc Function
- SAP Converting Data into IDoc Segment Format
- SAP Partner Profiles and Ports
- SAP Defining the partner profile for ALE IDOC
- SAP Data Ports ( WE21 ) in idoc
- SAP RFC in R/3
- SAP Workflow from Change Documents
- SAP ALE Distribution Scenario
- SAP Useful ALE Transaction Codes
- BAPI Creating IDocs and ALE Interface
- R/3 RFC from MS Office Via Visual Basic
- SD WORK FLOW SCENARIOS I
- SD WORK FLOW SCENARIOS II
- SD WORK FLOW SCENARIOS III
- SD WORK FLOW SCENARIOS IV
- SD WORK FLOW SCENARIOS V
- SD WORK FLOW SCENARIOS VI
- SD WORK FLOW SCENARIOS VII
- MM WORK FLOW SCENORIOS I
- MM WORK FLOW SCENORIOS II
- MM WORK FLOW SCENORIOS III
- MM WORK FLOW SCENORIOS IV
- MM WORK FLOW SCENORIOS V
- MM WORK FLOW SCENORIOS VI
- MM WORK FLOW SCENARIOS VII
- MM WORK FLOW SCENARIOS VIII
- MM WORK FLOW SCENARIOS IX
- MM WORK FLOW SCENARIOS X
- MM WORK FLOW SCENARIOS XI
- WORK FLOW SCENARIOS in SAP ABAP
- SAP ABAP WORK FLOW I
- SAP ABAP WORK FLOW II
- SAP ABAP WORK FLOW III
- SAP ABAP Work Flow IV
- SAP ABAP Workflow Technology
- SAP OPTIMIZATION
- abap type key ward
- PERFORMENCE TIPS
- SAP ABAP INTERNAL TABLES IN BRIEF
- SAP ABAP RUN TIME ANALASIS
- MEMORY In SAP ABAP
- NAVIGATION In SAP ABAP
- WORK BENCH AND TOOLS In SAP ABAP
- DATA OBJECTS AND STATEMENTS In SAP ABAP
- INTERNAL PROGRAM MODULARIZATION In SAP ABAP
- SAP ABAP CONSITENCEY THROUGH INPUT CHECKS
- RUN TIME ENVIRONMENT In SAP ABAP
- SAP ABAP INTER TABLE OPERATIONS
- STATEMENTS In SAP ABAP
- SAP ABAP INTERNAL TABLES
- SAP ABAP SUB ROUTIENS
- SAP ABAP FUNCTION MODULES AND GROUPS
- SAP ABAP QUARY ADMINSTRATION
- SAP ABAP SAVING LISTS AND BACK GROUND PROCESSING
- SAP ABAP PROGRAM INTERFACE
- SAP ABAP LOCK CONCEPT
- SAP ABAP AUTHORISATION CHECKS
- SAP ABAP PERFORMENCE TIPS
- In SAP SYSTEM FIELDS
- SAP ABAP CONTROL BLOCKS
- SAP ABAP BUFFERING
- SAP ABAP MATCH CODE OBJECTS
- SAP ABAP LOCKS
- SAP SAMPLE CODE FOR OUTPUT TO EXCEL AND IN PUT FIL...
- SAP MULTIPLE INTERACTIVE REPORT SAMPLE CODE
- MULTIPLE INTERACTIVE REPORT SAMPLE CODE II
- CALLING PROGRAM AND PASSING DATA
- SAP TECHNIQUES FOR LIST CREATION AND SAP QUARY
- SAP SELECTION SCREENS ABAP REPORT
- SAP ABAP FAQ ON SCRIPTS I
- SAP ABAP FAQ ON SCRIPTS II
- SAP ABAP FAQ ON SCRIPTS III
- IN SAP ABAP TABLE TYPES
- SAP ABAP TYPES OF VIEWS
- SAP ABAP DATA BASE UPDATES COMPLETE
- SAP ABAP LOCK CONCEPT
- SAP ORGANIZING DATABASE UPDATES
- SAP ENHANCEMENTS TO DICTIONERY ELEMENTS
- DATA BASE DIALOG IN ABAP
- ABAP DICTIONARY I
- PERFORMANCE DURING TABLE ACCESS
-
▼
October
(145)
No comments:
Post a Comment