I have the following code snippet, that I would like to write in functional style :
data(lt_es) = me->prepare_process_part_ztoa1( ).
APPEND LINES OF me->prepare_process_part_protocol( ) to lt_es.
How to rewrite the code above in new ABAP 7.5?
Use the LINES OF construct (available since ABAP 7.40 SP 8).
For instance, it could be something like this:
lt_es = VALUE #( BASE me->prepare_process_part_ztoa1( )
( LINES OF me->prepare_process_part_protocol( ) ) ).
Whether it is better/simplier than the original, that's another question :)
It can be also done without BASE. However one must specify the type explicitly (usage of # ends with a syntax error).
REPORT ZZZ.
DATA: lt_t1 TYPE string_table,
lt_t2 TYPE string_table.
DATA(lt_t3) = VALUE string_table( ( LINES OF lt_t1 ) ( LINES OF lt_t2 ) ).
Would be interesting to know if this is maybe more performant than the usage of BASE if used in a loop for example.
Related
I am trying to see if there is a way to do the following
IF line_exists( company_accounts2[ saknr+0(2) = wa_company_accounts-saknr+0(wa_account_levels-num_of_digits) ] ).
ENDIF.
But the number 2 in saknr+0(2) with a parameter and specifically with the one that exists in the other side of equality (wa_account_levels-num_of_digits). Is there any way to do it with another way? Because if I replace the 2 with the wa_account_levels-num_of_digits I am getting the error "The length specification "WA_ACCOUNT_LEVELS-NUM_OF_DIGITS" is not numeric."
Thanks in advance
PS. What is not working and this is what I am asking below the above code is the following code:
IF line_exists( tab[ matnr+0(ls_mara-num_of_digits) = ls_mara-matnr+0(ls_mara-num_of_digits) ] ).
THIS CODE IS NOT WORKING.
Pass the left side of the equality as a text variable between parentheses, which contains the name of the variable and its offset:
DATA(lv_text) = |saknr+({ wa_account_levels-num_of_digits })|.
IF line_exists( company_accounts2[ (lv_text) = wa_company_accounts-saknr+0(wa_account_levels-num_of_digits) ] ).
CONTINUE.
ELSE.
"make the APPEND
ENDIF.
It works perfectly, for what you wanna achieve your wa_account_levels-num_of_digits should have primitive type i (INT1, INT2, INT4, INT8 in database).
Here is the working MARA sample
SELECT * UP TO 5 ROWS
FROM mara
INTO TABLE #DATA(tab).
READ TABLE tab INTO DATA(ls_mara) INDEX 1.
IF line_exists( tab[ matnr+0(2) = ls_mara-matnr+0(ls_mara-stfak) ] ).
ENDIF.
UPDATE: dynamic specification of the table components for read access is not possible:
If the data type of the components is character-like and flat, an offset/length +off(len) can be appended to the name of the component (as in substring access) to access subareas of the component. Only directly specified numbers or constants can be specified for off and len.
I'm working with an SQL block in RMarkdown and know that I can reference R variables like:
```{sql connection=db}
select * from [dbo].[B]
where BATCH_ID = ?BATCH_ID
```
Is there any special syntax that can be used to evaluate an R expression? I'm hoping I can do something like:
```{sql connection=db}
select * from [dbo].[B]
where BATCH_ID = ?RESULT$BATCH_ID
```
Is this possible?
OK, Found https://github.com/yihui/knitr/blob/ca04aa42ca59740408013dab7e6172af1c92f20d/R/engine.R and from line 429 onwards I can see the code for processing the variable substitutions. It just looks for variables, no evaluation of expressions, but at least I know where to go now to add that if I want to.
In the short term, I added the following to mass-pollute my environment with the variables I needed (didn't want to be eeking them out one-by-one).
mapply(FUN=assign, names(RESULT), RESULT, MoreArgs=list(pos=1))
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.
Is there any Function module that can generate ABAP code.
For eg: FM takes tables name and join conditions as input and generate ABAP code corresponding to that.
Thanks
You should consider using SAPQuery. SAP documentation here: https://help.sap.com/saphelp_erp60_sp/helpdata/en/d2/cb3efb455611d189710000e8322d00/content.htm
1. Generic reports are possible.
Your problem is, that You will have to draw a strict frame of what is
generic and what not, this means, some stuff MUST be that generic, that
it will deal with WHATEVER You want to do before ( mostly the selection ) ,
during ( mostly manipulation ---> I would offer a badi for that ), and output.
This means, that there is at least the output-step, which can be valid for ALL
data resulting from the steps before.
Consider a generic ALV-table_output, there are a lot of examples in the repo.
If You want to be the stuff printed out simple as list, this might include
more work, like, how big is the structure, when Dou You wrap a line, and so on, consider using a flag which allows to toggle the type of output .
2. Generic reports are a transportable object.
This refers to point one. Define clear stages and limits. What does the report do, and what is it not able to do. Because, even if it is in customer's namespace, each modification still will be put into transport-layers. Therefore a strict definition of features/limits is necessary so that the amount of transports due to "oh, but we also need that"-statements will not become infinite.
2. Generic reports are strict.
What does that mean ? You might want to parse the passed data ( table names, join-binding, selection-parameter-values ) and throw exceptions, if not properly set. Much work. You should offer a badi for that. If You do not do this, expect a dump. let it dump. In the end the user of Your report-api should know ( by documentation perhaps) how to call it. If not, a dynamic SQL-dump will be the result.
3. Generic reports might benefit from badis/exits.
This is self explanaining, I think. Especially generic/dynamic selection/modification/displaying of data should be extendable in terms of
custom-modifications. When You inspect, what a f4-search-help exit works like, You will understand, what I mean.
4. Generic coding is hard to debug, mostly a blackbox.
Self explaining, in the code-section below I can mark some of those sections.
5. Generic coding has some best prectice examples in the repo.
Do not reinvent the wheel. Check, how the se16n works by debugging it,
check how se11 works by debugging it. Check, what the SQL-Query-builder
looks like in the debugger. You will get the idea very soon,
and the copy-paste should be the most simple part of Your work.
6. That are the basic parts of what You might use.
Where clause determination and setting the params.
data lt_range type rsds_trange.
data ls_range_f type rsds_frange.
data lt_where type rsds_twhere.
data ls_where like line of lt_where.
ls_range_f = value #( sign = _sign
option = _option
low = _low
high = _high ).
.
.
.
append ls_frange to lt_range.
.
.
.
call function 'FREE_SELECTIONS_RANGE_2_WHERE'
exporting
field_ranges = lt_range
importing
where_clauses = lt_where.
You have the parameter, let us create the select-result-table.
data(lt_key) = value abap_keydescr_tab( for line in _joinfields)
( name = fieldname ) ).
data(lo_structdescr) = cast cl_abap_structdescr( cl_abap_structdescr=>describe_by_name( _struct_name ) ).
data(lo_tabledescr) = cl_abap_tabledescr=>create( line_type = lo_structdescr p_key = lt_key ).
create data ro_data type handle lo_tabledescr.
.
.
.
select (sel_st)
from (sel_bind)
into corresponding fields of table t_data
where (dyn_where).
Then assign the seelct-table-result-reference to the generic table of this select.
Do You need more hints ?
Yes, such possibility exists, but not by means of function modules. INSERT REPORT statement allows generating report by populating its code from internal text table:
INSERT REPORT prog FROM itab
[MAXIMUM WIDTH INTO wid]
{ [KEEPING DIRECTORY ENTRY]
| { [PROGRAM TYPE pt]
[FIXED-POINT ARITHMETIC fp]
[UNICODE ENABLING uc] }
| [DIRECTORY ENTRY dir] }.
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...