Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Problem with cl_salv_gui_table_ida

frankgutknecht
Participant
0 Likes
4,595

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

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

16 REPLIES 16
Read only

jasmin_gruschke
Product and Topic Expert
Product and Topic Expert
0 Likes
4,014

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

Read only

0 Likes
4,014

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

Read only

0 Likes
4,014

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

Read only

0 Likes
4,014

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

Read only

JensWeiler
Product and Topic Expert
Product and Topic Expert
0 Likes
4,014

Hi Frank,

which SP of AS ABAP do you have installed ?

Thanks Jens

Read only

0 Likes
4,014

Hi Jens,

ABAP 7.4 SP10

Frank

Read only

0 Likes
4,014

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

Read only

0 Likes
4,014

Hi Jasmin,

our Hana Version is:

HDB 1.00.097.01.1436865239

Cheers,

Frank

Read only

0 Likes
4,014

Hi Jasmin, hi Jens,

are there any news about this problem?

Thanks!

Cheers

Frank

Read only

0 Likes
4,014

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

Read only

0 Likes
4,014

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

Read only

0 Likes
4,014

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

Read only

frankgutknecht
Participant
0 Likes
4,014

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

Read only

ivo_vollrath
Product and Topic Expert
Product and Topic Expert
0 Likes
4,014

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

Read only

0 Likes
4,014

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!

Read only

ivo_vollrath
Product and Topic Expert
Product and Topic Expert
0 Likes
4,014

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