Problem with cl_salv_gui_table_ida

[frankgutknecht]

Hello,

I'm using the new ALV 'cl_salv_gui_table_ida' combined with a Core Data Service. I've activated the toolbar text search and enabled the search for a plenty of columns:

    go_alv_display->field_catalog( )->enable_text_search( 'NAME1' ).

    go_alv_display->field_catalog( )->enable_text_search( 'ORT01' ).

    go_alv_display->field_catalog( )->enable_text_search( 'PSTLZ' ).

    go_alv_display->field_catalog( )->enable_text_search( 'INFNR' ).

    go_alv_display->field_catalog( )->enable_text_search( 'LIFNR' ).

    go_alv_display->field_catalog( )->enable_text_search( 'LIFNR_2' ).

    go_alv_display->field_catalog( )->enable_text_search( 'MAKTX' ).

    go_alv_display->field_catalog( )->enable_text_search( 'SMTP_ADDR' ).

    go_alv_display->field_catalog( )->enable_text_search( 'ORT02' ).

The search is working for the fields NAME01, ORT01, PSTLZ, MAKTX, ORT02, The other columns don't work in the search.

I've checked the coding and found out that the search_scope is just filled with the working columns.

Class: CL_SADL_ABQI

Method: _GET_SEARCH_SCOPE

But I couldn't find the coding where the scope is filled.

Thx for your help!

Frank

[jasmin_gruschke]

Hi Frank,
can you give some more details about which DB tables the CDS view depends on? I assume it has something to do with the data element types, but I only found that LIFNR/INFNR are CHAR 10's, don't have type information about the working fields like MAKTX (TEXT??).
Cheers,
  Jasmin

[frankgutknecht]

Hi Jasmin,

of course, the dependent TB tables in the CDS are:

llfa1.lifnr,

lfa1.ort01,

lfa1.pstlz,

eina.matnr,

makt.maktx,

adr6.smtp_addr,

lfa1.name1,

eina.infnr

lfa1.ort02,

for example maktx is a CHAR 40 field.

The only thing i noticed is that all the non-searchable fields have some conversion routines.

Frank

[jasmin_gruschke]

Hi Frank,
just checked with *the* expert.

[By the way: The situation is the very same if you go for the table directly (e.g. using field LIFRN and NAME1 from LFA1) in the ALV IDA. So it's not related to the CDS view.]

So, the issue originates (as you already guessed yourself) from the ALPHA CONVERSION, which complicates the search on DB level (which depends on an internal format).

As a workaround, you could either do e.g. a cast( lifnr as abap.char(10)) in the CDS view, or a cast to a dedicated data element MY_LIFNR, which uses a copy of the original domain but removes the conversion exit.

Cheers,
  Jasmin

[frankgutknecht]

Hi Jasmin,

thanks for your help!

If I try to casts the fields:

cast(lfa1.lifnr as abap.char(10)) as lifnr,

I'm getting an dump if I start to search.

"feature not supported: An expression (not field) cannot be supported"

How do use a dedicated data element in a CDS-View?

Cheers,
Frank

[JensWeiler]

Hi Frank,

which SP of AS ABAP do you have installed ?

Thanks Jens

[frankgutknecht]

Hi Jens,

ABAP 7.4 SP10

Frank

[jasmin_gruschke]

Hi Frank,
yet another question arises, which HANA version/revision are you running (as the error message seems to originate from the DB rather than from the ABAP layer).
Cheers,
  Jasmin

[frankgutknecht]

Hi Jasmin,

our Hana Version is:

HDB 1.00.097.01.1436865239

Cheers,

Frank

[frankgutknecht]

Hi Jasmin, hi Jens,

are there any news about this problem?

Thanks!

Cheers

Frank

[jasmin_gruschke]

Hi Frank,
sorry for the late reply. Yes, acutally there is an update. Seems that there is an issue in the interplay of the ALV and the CONTAINS function in your HDB revision.
I guess asking you to upgrade your HANA is not an option, therefore, I propose to use another workaround.

I previously proposed to use a CAST on a dedicated data element MY_LIFNR (which does not feature an ALPHA CONVERSION). Can you alternatively use such a data element in combination with the method field_catalog()->set_data_element( ... ) function of your IDA ALV before calling the enable_text_search( ... ) function?

Works for me, but I don't have a system with exaclty the same versions (ABAP and HANA) you have in your system.

Best,
  Jasmin

[frankgutknecht]

Hi Jasmin,

we have upgraded our System to

HDB 1.00.102.03.1449674847

and the problem still exists. We cannot search for elements if they have a conversion routine.

The Cast of the Element is not working. I'm still getting a dump:

"feature not supported: An expression (not field) cannot be supported"

Thanks for your help.

Best,

Frank

[frankgutknecht]

Hi Jasmin,

we've updated our system again to

1.00.112.00.1457615240

and the problem still exists. Do you have any news about this?

Thank you!

Frank

[frankgutknecht]

Hello,

i've found the place in the coding.

Class: CL_SALV_GUI_FIELD_CATALOG_IDA

Method: GET_ALLOWED_SERVICES

if ls_display_info-is_text_search_allowed eq abap_true

       and l_inttype NA 'IPbsaef'

       AND l_convexit IS INITIAL.  "OR l_inttype EQ 'N' ). "Not Numeric and no ConvExit U4YK011340

         is_text_search_allowed = abap_true.

       endif.

The Conversion Routine has to be initial. Is there any special reason?

Please change the SAP Standard! 😄

Best regards

Frank

[ivo_vollrath]

Hi Frank,

I just saw your question. Thank you for citing the place in the coding!

Yes, there is a reason: When a column has a conversion exit, it does not make much sense to do a text-search on the values stored on the database. They would have to be converted before matching.

Conversion exits are "evil" in the age of HANA-based applications.

Kind Regards,

Ivo

[frankgutknecht]

Hi Ivo,

and what is the solution for my problem?

There are plenty of conversion routines in the SAP ERP Standard. I think the user should have the possibility to search for fields even if they have a conversion routine.

Thanks!

[ivo_vollrath]

Hi Frank,

I am honestly sorry for having read only part of your thread. I saw the discussions about the HANA revision, but I missed the other important parts.

I did not try it but I would expect that the following (roughly) should work:

go_alv_display->field_catalog()->set_data_element( iv_field_name = 'LIFNR' iv_data_element_name = 'MY_LIFNR' ).

where MY_LIFNR would by your own copy of the LIFNR data type without conversion exit.

Of course, this would only be a partial solution as it would disable the conversion exit completely for your table. Depending on what the conversion exit actually does, this may or may not make sense.

Therefore, your general concerns about conversion exits being used all over the standard are, of course, valid.

Kind Regards,

Ivo