Application Development 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: 

Long string not allowed in WHERE clause

h_senden2
Active Contributor
0 Kudos

hi,

in my program on Netweaver 7.02 I'm using a SELECT with a WHERE clause on a long string :

SELECT * INTO TABLE it_edid4

    FROM edid4

    FOR ALL ENTRIES IN it_edidc

    WHERE docnum = it_edidc-docnum

      AND segnam = 'E1RDID'

      AND sdata LIKE 'HEADER    HEADER_DATA                   WA_HEADER_DATA-BILLNO%'.

This works great on NW702.

But now we are upgrading to NW740, and the statement is not allowed anymore 😞

Error message :

The field SDATA is a long string or a text and cannot be used in the WHERE condition.

Is there a good alternative to perform this select ?

Performance wise it's not good to first read all entries, loop over them and check the SDATA field.

gr

Hans

1 ACCEPTED SOLUTION

Jelena
Active Contributor
0 Kudos

Why do you need this? If you're on 7.4 then most likely you also have the new IDoc monitor transaction WLF_IDOC that can search for the segment content. It runs quite fast in our environment and is much more convenient than the old WE09 transaction.

If you still must have a custom report then maybe it's worth checking the code in that transaction.

5 REPLIES 5

matt
Active Contributor
0 Kudos

The release notes say:

Corrections when using the predefined types LCHR and LRAW from ABAP Dictionary.

Columns of the types LCHR and LRAW cannot be used in comparisons of the WHERE condition. Before Release 7.40 SP02, this produced a runtime error. From Release 7.40 SP02, this also produces a syntax error (if statically identifiable).

...which indicates you should have been getting a runtime error with your select! So it's a bit odd that it used to work.

I'm afraid I cannot think of an alternative approach to what you've already suggested - expect possibly using an INNER JOIN instead of FOR ALL ENTRIES, if that's feasible.

h_senden2
Active Contributor
0 Kudos

No runtime error on the NW702 system. And a good performance.

Unfortunately I have to search another solution.

Patrick_vN
Active Contributor
0 Kudos

Have you tried dropping the sdata part from the selection and sorting the data afterwards? I understand that it will be slower then before, but the question is whether it will be noticeable slower, not?

former_member186746
Active Contributor
0 Kudos

Hi,

I think performance wise it shouldn't be longer than you had previously.

Unfortunately you don't have data to test the differences.

Kind regards, Rob Dielemans

Jelena
Active Contributor
0 Kudos

Why do you need this? If you're on 7.4 then most likely you also have the new IDoc monitor transaction WLF_IDOC that can search for the segment content. It runs quite fast in our environment and is much more convenient than the old WE09 transaction.

If you still must have a custom report then maybe it's worth checking the code in that transaction.