07-08-2016 6:51 AM
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
07-08-2016 4:57 PM
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.
07-08-2016 9:25 AM
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.
07-08-2016 2:43 PM
No runtime error on the NW702 system. And a good performance.
Unfortunately I have to search another solution.
07-08-2016 3:45 PM
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?
07-08-2016 4:02 PM
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
07-08-2016 4:57 PM
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.