My scenario is that I am getting an IDOC segment's data into a field symbol and change some fields based on some validations.
My code:
READ TABLE idoc_data ASSIGNING FIELD-SYMBOL(<idocdata>) with key = 'E1EDK01'
IF sy-subrc = 0.
lcl_struc ?= cl_abap_typedescr=>describe_by_name( 'E1EDK01' ).
CREATE DATA dref TYPE HANDLE lcl_struc.
ASSIGN dref->* TO FIELD-SYMBOL(<sdata>).
IF <sdata> IS ASSIGNED.
<sdata> = <idocdata>-sdata.
....
<idocdata>-sdata = <sdata>.
ENDIF.
ENDIF.
Though the above snippet works fine, the continuity of field symbols is broken and now I have to pass back the changed data. How do I use ASSIGN and let the field symbols take care of the changes rather than an explicit statement?
Something similar to below snippet though this won't work since <IDOC_DATA>-SDATA and <SDATA> aren't compatible.
READ TABLE idoc_data ASSIGNING FIELD-SYMBOL(<idocdata>) with key = 'E1EDK01'
IF sy-subrc = 0.
FIELD-SYMBOLS: <sdata> TYPE E1EDK01.
ASSIGN <idocdata>-sdata TO <sdata>.
....
ENDIF.
My expectation is that when I change the data in <SDATA>-FIELD1, I want the changes to flow into <IDOCDATA>-SDATA without using <idocdata>-sdata = <sdata>.
As #Sandra mentioned above, the incompatibility of field-symbols can be resolved by using CASTING while assigning them. This would make the second snippet work.
...
IF sy-subrc = 0.
FIELD-SYMBOLS: <sdata> TYPE E1EDK01.
ASSIGN <idocdata>-sdata TO <sdata> CASTING.
...
ENDIF.
Related
I'm currently trying to perform a dynamic lossless assignment in an ABAP 7.0v SP26 environment.
Background:
I want to read in a csv file and move it into an internal structure without any data losses. Therefore, I declared the field-symbols:
<lfs_field> TYPE any which represents a structure component
<lfs_element> TYPE string which holds a csv value
Approach:
My current "solution" is this (lo_field is an element description of <lfs_field>):
IF STRLEN( <lfs_element> ) > lo_field->output_length.
RAISE EXCEPTION TYPE cx_sy_conversion_data_loss.
ENDIF.
I don't know how precisely it works, but seems to catch the most obvious cases.
Attempts:
MOVE EXACT <lfs_field> TO <lfs_element>.
...gives me...
Unable to interpret "EXACT". Possible causes: Incorrect spelling or comma error
...while...
COMPUTE EXACT <lfs_field> = <lfs_element>.
...results in...
Incorrect statement: "=" missing .
As the ABAP version is too old I also cannot use EXACT #( ... )
Example:
In this case I'm using normal variables. Lets just pretend they are field-symbols:
DATA: lw_element TYPE string VALUE '10121212212.1256',
lw_field TYPE p DECIMALS 2.
lw_field = lw_element.
* lw_field now contains 10121212212.13 without any notice about the precision loss
So, how would I do a perfect valid lossless assignment with field-symbols?
Don't see an easy way around that. Guess that's why they introduced MOVE EXACT in the first place.
Note that output_length is not a clean solution. For example, string always has output_length 0, but will of course be able to hold a CHAR3 with output_length 3.
Three ideas how you could go about your question:
Parse and compare types. Parse the source field to detect format and length, e.g. "character-like", "60 places". Then get an element descriptor for the target field and check whether the source fits into the target. Don't think it makes sense to start collecting the possibly large CASEs for this here. If you have access to a newer ABAP, you could try generating a large test data set there and use it to reverse-engineer the compatibility rules from MOVE EXACT.
Back-and-forth conversion. Move the value from source to target and back and see whether it changes. If it changes, the fields aren't compatible. This is unprecise, as some formats will change although the values remain the same; for example, -42 could change to 42-, although this is the same in ABAP.
To-longer conversion. Move the field from source to target. Then construct a slightly longer version of target, and move source also there. If the two targets are identical, the fields are compatible. This fails at the boundaries, i.e. if it's not possible to construct a slightly-longer version, e.g. because the maximum number of decimal places of a P field is reached.
DATA target TYPE char3.
DATA source TYPE string VALUE `123.5`.
DATA(lo_target) = CAST cl_abap_elemdescr( cl_abap_elemdescr=>describe_by_data( target ) ).
DATA(lo_longer) = cl_abap_elemdescr=>get_by_kind(
p_type_kind = lo_target->type_kind
p_length = lo_target->length + 1
p_decimals = lo_target->decimals + 1 ).
DATA lv_longer TYPE REF TO data.
CREATE DATA lv_longer TYPE HANDLE lo_longer.
ASSIGN lv_longer->* TO FIELD-SYMBOL(<longer>).
<longer> = source.
target = source.
IF <longer> = target.
WRITE `Fits`.
ELSE.
WRITE `Doesn't fit, ` && target && ` is different from ` && <longer>.
ENDIF.
I'm trying to save a SAP internal table to SAP Directory as .CSV file. I've learned that I should convert the contents to character type but i get an illegal casting error.
This is my code:
FORM f_opendata TABLES p_tab TYPE STANDARD TABLE USING
p_work TYPE any.
FIELD-SYMBOLS: <lfs_wa>.
CONCATENATE c_headerfile c_initials sy-datum c_ext INTO v_dtasetfile.
OPEN DATASET v_dtasetfile FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc EQ 0.
LOOP AT p_tab INTO p_work.
ASSIGN p_work TO <lfs_wa> CASTING TYPE c.
TRANSFER <lfs_wa> TO v_dtasetfile.
ENDLOOP.
CLOSE DATASET v_dtasetfile.
MESSAGE i899(f2) WITH 'SUCCESS' v_dtasetfile.
ENDIF.
ENDFORM.
This is the error:
An exception occurred that is explained in detail below.
The exception, which is assigned to class CX_SY_ASSIGN_CAST_ILLEGAL_CAST, was
not caught in procedure F_OPENDATA, nor was it propagated by a RAISING clause.
Since the caller of the procedure could not have anticipated that the
exception would occur, the current program is terminated.
The reason for the exception is:
The error occurred at a statement of the form
ASSIGN f TO CASTING.
ASSIGN f TO CASTING TYPE t.
or
ASSIGN f TO CASTING LIKE f1.
or
at table statements with the addition
ASSIGNING CASTING.
The following error causes are possible:
1. The type of field f or the target type determined by , t or f1
contains data references, object references, strings or internal tables
as components.
These components must match exactly as far as their position (offset)
and their type are concerned.
2. The specified type t or the type of f1 are not suited for the type of
the field symbol .
3. The row type of the related table is not suited for the target type
specified by according to the rules described in 1).
Converting isn't the same thing as casting. If your table contains fields that are not CLIKE, the system will refuse to cast the entire line. You have two options at this point:
ensure that your output table only contains character-like fields or
walk through each field of each line (you can use RTTI to do this) and convert the contents as required
I used a function to covert to text format before I transfered data to the dataset:
CALL FUNCTION 'SAP_CONVERT_TO_TEX_FORMAT'
EXPORTING
I_FIELD_SEPERATOR = c_colon
TABLES
I_TAB_SAP_DATA = ig_final
CHANGING
I_TAB_CONVERTED_DATA = ig_text
EXCEPTIONS
CONVERSION_FAILED = 1
OTHERS = 2
.
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
OPEN DATASET v_g_dtasetfile FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc EQ 0.
LOOP AT ig_text ASSIGNING <fs_l_wa>.
TRANSFER <fs_l_wa> TO v_g_dtasetfile.
ENDLOOP.
CLOSE DATASET v_g_dtasetfile.
MESSAGE i899(f2) WITH text-020 v_g_dtasetfile text-021.
ENDIF.
As I rarely loop into a field symbol, I often forget to use ASSIGNING instead of INTO which will promptly cause an abend. Is there a valid use of INTO with <fieldsymbol> or is this something that the syntax checker really ought to catch?
LOOP...INTO is perfectly valid but it will work differently. LOOP...INTO transports the values to the structure provided but ASSIGNING assigns the field symbol to the actual table rows.
The only difference is if you are going to change the table contents. See the following:
* Changes all entries in the CARRID column of lt_flights to 50.
LOOP AT lt_flights ASSIGNING <flight>.
<flight>-carrid = 50.
ENDLOOP.
* Does not change the entries in lt_flights (MODIFY...FROM would be required).
ASSIGN <flight> TO ls_flight.
LOOP AT lt_flights INTO <flight>.
<flight>-carrid = 50.
ENDLOOP.
LOOP...INTO with a field symbol would be useless unless you had some kind of dynamic programming requirement.
It is valid when <fieldsymbol> was previously assigned to a structure which has the type of the lines of the table you loop over.
It is a perfectly valid statement:
APPEND INITIAL LINE TO lt_foo ASSIGNING <ls_foo>.
READ TABLE lt_bar INTO <ls_foo> INDEX 1.
A field symbol just takes the place of a variable - at almost any point - so the syntax check can't flag this as invalid. It might issue a warning, though...
I am trying to add a new record to my internal table and this code is giving me an error, but I am doing exactly the same thing as in my SAP book. What am I doing wrong?
TYPES : BEGIN OF personel_bilgileri,
Ad TYPE c LENGTH 20,
Soyad TYPE c LENGTH 20,
Telefon_no Type n LENGTH 12,
END OF personel_bilgileri.
TYPES personel_bilgi_tablo_tipi TYPE STANDARD TABLE OF
personel_bilgileri WITH NON-UNIQUE KEY ad soyad.
DATA : personel_bilgi_kaydi TYPE personel_bilgileri,
personel_bilgi_tablosu TYPE personel_bilgi_tablo_tipi.
personel_bilgi_kaydi-ad = 'Murat'.
personel_bilgi_kaydi-soyad = 'Sahin'.
personel_bilgi_kaydi-telefon_no = '5556677'.
APPEND personel_bilgi_kaydi TO personel_bilgileri.
personel_bilgi_kaydi-ad = 'Ayse'.
personel_bilgi_kaydi-soyad = 'Bil'.
personel_bilgi_kaydi-telefon_no = '5556611'.
APPEND personel_bilgi_kaydi TO personel_bilgileri.
personel_bilgi_kaydi-ad = 'Mehmet'.
personel_bilgi_kaydi-soyad = 'Kalan'.
personel_bilgi_kaydi-telefon_no = '5556622'.
APPEND personel_bilgi_kaydi TO personel_bilgileri.
Actually, I don't know which adding record method I should use. I mean there is too many ways to do this operation. Which method will be the true one?
I am getting this error:
The field Personel_bilgileri is unknown, but there are following fields similar names...
Moreover, I can do this with LOOP AT, but I didn't understand the usage of LOOP AT. What does it do?
In your code sample, you first defined PERSONEL_BILGILERI as a TYPE, then PERSONEL_BILGI_TABLO_TIPI as a internal table TYPE of PERSONEL_BILGILERI.
Up to that point, no variables are declared yet. Only data types.
Then:
PERSONEL_BILGI_KAYDI is defined of type PERSONEL_BILGILERI. This is a structure that you use as a work area (which is fine).
PERSONEL_BILGI_TABLOSU is defined of type PERSONEL_BILGI_TABLO_TIPI. So PERSONEL_BILGI_TABLOSU is your internal table.
When you APPEND your work area, you have to append to an internal table, not a data type. try with PERSONEL_BILGI_TABLOSU instead of your type PERSONEL_BILGI:
APPEND personel_bilgi_kaydi TO personel_bilgileri_tablosu.
You need to APPEND your WA(workarea, personel_bilgi_kaydi) in to your table (personel_bilgi_tablosu). You cant append the WA to the defined type.
So it should look like this:
APPEND personel_bilgi_kaydi TO personel_bilgi_tablosu.
Also you can use this code to show them on the page.
LOOP AT personel_bilgi_tablosu into personel_bilgi_kaydi.
write: / 'İSİM: ' ,personel_bilgi_kaydi-ad,
'SOYİSİM: ',personel_bilgi_kaydi-soyad,
'TEL NO: ', personel_bilgi_kaydi-telefon_no.
ENDLOOP.
You can use other methods to show your table on the page, such as REUSE_ALV_GRID_DISPLAY. You can get more information about that in scn.sap.com
Hope it was helpful.
Kolay gelsin.
Talha
I have a deep structure that I would like to display as a tree with the values of each field (sort of like the hierarchical display of a structure you can do in SE11, but with values).
Is there a class or function that does this for you? I really don't want to have to go reinvent the wheel.
Well, I would say it is faster to do DIY then to search for something generic enough to help you. You can try following coding as basis.
It does the plain recursion through the variable (be it table or structure) and it prints the fields found at bottom...
*&---------------------------------------------------------------------*
*& Form print_structure
*&---------------------------------------------------------------------*
form print_structure using im_data.
data: lr_typeref type ref to cl_abap_typedescr,
lf_ddic_in type fieldname,
lt_dfies type ddfields,
lf_string type c length 200.
field-symbols: <lt_table> type any table,
<ls_table> type any,
<lf_field> type any,
<ls_dfies> like line of lt_dfies.
lr_typeref = cl_abap_typedescr=>describe_by_data( im_data ).
case lr_typeref->type_kind.
when cl_abap_typedescr=>typekind_table. " internal table
assign im_data to <lt_table>.
loop at <lt_table> assigning <ls_table>.
perform print_structure using <ls_table>.
endloop.
when cl_abap_typedescr=>typekind_struct1 or
cl_abap_typedescr=>typekind_struct2. " deep/flat structure
lf_ddic_in = lr_typeref->get_relative_name( ).
call function 'DDIF_FIELDINFO_GET'
exporting
tabname = lf_ddic_in
all_types = 'X'
tables
dfies_tab = lt_dfies
exceptions
not_found = 1
others = 0.
check sy-subrc eq 0.
loop at lt_dfies assigning <ls_dfies>.
assign component <ls_dfies>-fieldname of structure im_data to <lf_field>.
perform print_structure using <lf_field>.
endloop.
when others. " any field
write im_data to lf_string.
write: / lf_string.
endcase.
endform. "print_structure
Would an ALV Tree work? CL_SALV_TREE
I've never seen such functionality and think there is no one in standard. Can't remeber any situation in standard where such functionality should be used. In my opinion most appropriate way to implement this - to use Column Tree. Take a look into SAPCOLUMN_TREE_CONTROL_DEMO