‎2006 Nov 16 7:05 AM
hi all,
what is the difference between declaring a variable using type and like.
‎2006 Nov 16 7:10 AM
Hi,
when u r referring to a datatype then use type declaartion,when u r referring to any data base object,then use the like statement.
Regards,
Nagaraj
‎2006 Nov 16 7:10 AM
Hi,
when u r referring to a datatype then use type declaartion,when u r referring to any data base object,then use the like statement.
Regards,
Nagaraj
‎2006 Nov 16 7:24 AM
Hi sanjeev,
1. When you take reference of objects that occupies memory ( data elements,variables decalared with DATA) then use LIKE and when you are taking ref. to a elementry data types(C,I,D,T...) or to a variables decalared with TYPES statement then we use TYPE
regards,
amit m.
‎2006 Nov 16 7:35 AM
‎2006 Nov 16 7:38 AM
Hi sanjeev,
1.
For all practical purposes there are the same. The only additional advantage with types is that you can define your own types(including complex ones) in the data dictionary and reuse them accross various programs.
But within a program if two variables are defined one using LIKE and another using TYPE, both referring to the same field, then there is no difference.
If I include a type pool within a program, then I can define my variables only using TYPE to refer to any type defined in that pool. I cannot use LIKE in this scenario. Also, if I want to use native types like C, N, etc, I cannot use LIKE there either. I can use LIKE ABC only if ABC is in the database or if ABC is defined previously in the same program.
I can use TYPE ABC, if ABC is defined in database as a TYPE and included in the program with the statement TYPE-POOLS. I can use it, if it is the native types. I can use it, if it is already defined in the dictionary as a structure/table or structure/table field, or even if it is defined as a data element or a domain. So I can declare a variable V_BUKRS TYPE BUKRS, but I cannot define a variable V_BUKRS LIKE BUKRS.
But if I intend to use V_BUKRS to store company code, I will prefer to declare it as V_BUKRS LIKE T001-BUKRS, only because if tomorrow for some reason, the definition of T001-BUKRS changes to a data element for example, BUKRS_N(say DEC 4) instead of the data element BUKRS(CHAR 4) that it refers to now, I don't have to change my programs because I am referring to the table field and inhereting its properties. Whereas, had I declared my V_BUKRS TYPE BUKRS and the table now changed to BUKRS_N, I will be forced to change my program as there will be a type incompatability.
2. try this code (just copy paste)
report abc.
types : char50(50) type c.
*----
type.
data : d1 type c, "--- native
d2 type n, "--- native
d25 type char50 , "----
User defined data type
d3 type bukrs, "---- data element / domain
d4 type persno, "---- data element / domain
d5 type t001, "---- table
d99 type c
.
data :
*l1 like c "----
Not Allowed
*l2 like n "----
Not Allowed
*l25 like char50 , "----
User defined data type
*l3 like bukrs "----
Not Allowed
*l4 like persno, "----
Not Allowed
l5 like t001 , "---- table
l99 like pa0001
.
I hope it helps.
regards,
amit M.
‎2006 Nov 16 7:46 AM
look this to get some idea...
DATA - Simple Field Definitions
Variants:
1. DATA f.
2. DATA f(len).
Variant 1
DATA f.
Additions:
1. ... TYPE type
2. ... LIKE f1
3. ... TYPE LINE OF itabtype
4. ... LIKE LINE OF itab
5. ... TYPE REF TO cif
6. ... TYPE REF TO DATA
7. ... VALUE lit
8. ... DECIMALS n
9. ... READ-ONLY
In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See New Naming Convention.
Effect
Creates an internal field f in the program with default length. If you do not specify a data type, the object assumes the default type C.
A type name can be up to 30 characters long. The name may only consist of alphanumeric characters and the underscore character. It may not consist entirely of digits. Special characters such as German umlauts are not allowed. As well as these characters, certain special characters are used internall. However, these should not be used in application programs. SPACE is a reserved name, and cannot therefore be used. Furthermore, you should not use a field in a statement if it has the same name as one of the additions of the keyword (for example: PERFORM SUB USING CHANGING.).
Recommendations for Type Names:
Always start the name with a letter.
Use the underscore to separate compound names (for example, NEW_PRODUCT.
Additional help
Variables
Addition 1
... TYPE type
Effect
Creates the field f with the type type. The type can be one of the predefined types listed below, one of your own that you defined in the same program using TYPES, or a global type stored in the ABAP Dictionary The default length SL of the field f depends on its data type type.
Type Description of type SL Initial value
C Character 1 Space
N Numeric string 1 '00...0'
D Date (YYYYMMDD) 8 '00000000'
T Time: HHMMSS) 6 '000000'
X Byte (hexadecimal) 1 X'00'
I Integer 4 0
P Packed number 8 0
F Floating point number 8 '0.0'
STRING String Variable empty string
XSTRING byte sequence (XString) Variable empty X string
Example
DATA NUMBER TYPE I.
Field NUMBER is created with type I, and can then be used in the program. In particular, you can assign numeric values to the field and use it to perform calculations (ABAP numeric types).
Addition 2
... LIKE f1
In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See LIKE references to ABAP Dictionary types not allowed.
Effect
Creates the field f with the same field attributes as the data object (already defined) f1. You can use this technique for any data type (fields, parameters, structures) as long as the data object is fully typed.
f1 can be any ABAP Dictionary reference.
Example
DATA TABLE_INDEX LIKE SY-TABIX.
TABLE_INDEX now has the same attributes as SY-TABIX (the index field for internal tables).
Note
You should use this addition wherever possible. If the type of a field to which you have referred changes, the ABAP runtime system automatically adopts the change in all fields defined with reference to it. It also avoids unnecessary and unwanted conversions.
Addition 3
... TYPE LINE OF itabtype
Effect
The type itabtype must be the type of an internal table. The system creates a data object with the line type of the specified table type.
Example
TYPES TAB_TYPE TYPE STANDARD TABLE OF I WITH NON-UNIQUE
DEFAULT KEY INITIAL SIZE 10.
DATA TAB_WA TYPE LINE OF TAB_TYPE.
The data object TAB_WA now has the same attributes as a line of the table type TAB_TYPE - in this case, type I.
Addition 4
... LIKE LINE OF itab
In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See LIKE references to ABAP Dictionary types not allowed.
Effect
The data object itab must be an internal table with or without a header line. The system creates a data object with the line type of the specified table.
Example
DATA TAB TYPE STANDARD TABLE OF I WITH NON-UNIQUE
DEFAULT KEY INITIAL SIZE 10.
DATA TAB_WA LIKE LINE OF TAB.
The data object TAB_WA now has the same attributes as a line of the table TAB (in this case, type I).
Addition 5
... TYPE REF TO cif
Effect
Declares the data object f as a reference variable in ABAP Objects, where cif is a class or interface. Reference variables contain references(pointers) to objects.
If you specify a reference variable with reference to a class, it can contain references to objects in that class. If you specify a reference variables with reference to an interface, it can contain references to objects whose class implements the interface.
Note
Objects (instances of class) can only be addressed using reference variables. For information about creating objects, see CREATE OBJECT.
Example
INTERFACE i1.
METHODS m1.
ENDINTERFACE.
CLASS c1 DEFINITION.
PUBLIC SECTION.
INTERFACES i1.
ENDCLASS.
CLASS c1 IMPLEMENTATION.
METHOD i1~m1.
...
ENDMETHOD.
ENDCLASS.
DATA: o1 TYPE REF TO c1,
o2 TYPE REF TO c1,
ir TYPE REF TO i1.
START-OF-SELECTION.
CREATE OBJECT o1.
o2 = o1.
ir = o1.
Additional help
Object Handling
Addition 6
... TYPE REF TO DATA
Effect
Declares the data object f as a reference variable.
Reference variables contain references (pointers) to data objects.
Example
DATA: numref TYPE REF TO DATA,
number TYPE I VALUE 123.
FIELD-SYMBOLS: <fs> TYPE ANY.
GET REFERENCE OF number INTO numref.
ASSIGN numref->* TO <fs>.
This example creates a reference to the data object number. It is then assigned to the field symbol <fs> using the dereferencing operator ->*. It is now possible to work with the field symbol in the normal way.
Addition 7
... VALUE lit
Effect
Instead of its initial value (indicated in the above table), the field f takes as its starting value the value of the literal lit. You may also specify a constant, or the addition IS INITIAL, in which case, the system uses the initial value for the data type of the object. This is particularly important when you use the CONSTANTS statement, since you must always use the VALUE addition.
Example
DATA: NUMBER TYPE I VALUE 123,
FLAG VALUE 'X',
TABLE_INDEX LIKE SY-TABIX VALUE 45.
The example creates a field NUMBER with type I. Instead of its initial value (0), it is created withe the starting value 123. The field FLAG with type C (length 1) now has the contents 'X'; TABLE_INDEX has the value 45, since the field SY-TABIX is a numeric field.
Addition 8
... DECIMALS n
Effect
This addition only applies to field type P. The field has n decimal places for calculations and display, where n can be between 0 and 14.
When you create a new program, "Fixed point arithmetic" is set by default. If you deselect this option, the DECIMALS specification does not apply to calculations, but only to display. In this case, you as the programmer are responsible for ensuring that you calculate correctly with decimals by multiplying or dividing by the relevant power of ten (COMPUTE).
You should always work with fixed point arithmetic, because the intermediate results of calculations (division!) are also calculated to the greatest possible accuracy (31 decimal places).
For hints on when to use the fixed point type P or the floating point type F, see "ABAP Number Types".
Addition 9
... READ-ONLY
Effect
You can only use this addition in the public visibility section (PUBLIC SECTION) of a class declaration (see CLASS) or in an interface definition (see INTERFACE).
The READ-ONLY addition makes a public attribute, declared in a DATA statement, readable from outside the class, but only modifiable by methods of the class.
Note
When inheritance is introduced, the READ-ONLY addition will also be permitted in the protected area. Subclasses of a class will then be able to change the READ-ONLY attributes in the public section, but not those in the protected section.
Example
CLASS C1 DEFINITION.
PUBLIC SECTION.
DATA A VALUE 'X' READ-ONLY.
METHODS M.
ENDCLASS.
DATA O TYPE REF TO C1.
CREATE OBJECT O.
CALL METHOD O->M.
WRITE O->A.
CLASS C1 IMPLEMENTATION.
METHOD M.
A = 'Y'.
ENDMETHOD.
ENDCLASS.
Attribute A of class C1 can only be read from outside the class. To change it, you need a method from the same class.
Additional help
Classes
Variant 2
DATA f(len).
Additions:
As in variant 1
Effect
Creates field f with the length len.
You can only use this variant with type C, N, P, and X fields. Fields with other types can only be created in their default length (see table under "Effects" of variant 1).
In an ABAP Objects context, a more severe syntax check is performed that in other ABAP areas. See Wrong length specified in declaration.
The maximum permitted length of a field depends on its type:
Type Permitted length
C 1 - 65535
N 1 - 65535
P 1 - 16
X 1 - 65535
Note
Each byte can store one character, or two decimal or hexadecimal digits. In a P field, one half-byte is reserved for the plus or minus sign. Consequently, a P field with length 3 can contain up to 5 digits, while an X field with length 3 can contain 6. Both have the output length 6.
Ramesh.
‎2006 Nov 16 9:03 AM