02-02-2023 2:16 PM
Hello,
What do you think about using SELECT/ENDSELECT in S4HANA while migrating from ECC. are we obliged to replace all occurences in source system or we can keep them. If you have any recommended links regarding this subject it'll be helpful.
Thank you in advance.
02-02-2023 2:25 PM
There is a lot of point of view, for me you could use it only for one case, if you have not the full key of a table and you are using the option UP TO 1 ROWS.
But the SELECT ... code ... ENDSELECT must be replaced, this is old school
02-02-2023 2:45 PM
Hello Ridwane,
I think you have to change SELECT...ENDSELECT statements to new form when it is possible since it is classified as obsolete statement in new releases of ABAP.
https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-us/abapselect_obsolete.htm
My best regards.
02-02-2023 3:10 PM
and if you go in the not-obsolet part, you'll find it also
https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-us/abapselect.htm
02-02-2023 4:19 PM
Thank you for your answer.
In the link you sent the SELECT/ENDSELECT is one of the good examples given at the end of the treatment.
so it is not obsolete
02-02-2023 7:54 PM
Select up to 1 rows is also old school. The optimiser issues exactly the same SQL to the db server.
Always use select single. It's cleaner.
02-02-2023 7:58 PM
I've read the documentation of select ... endselect. There are so many warning, I just don't see the point. Just use INTO TABLE.
If there's business logic between the SELECT.. ENDSELECT then that's not clean code.
Just don't use it. I've been programming in ABAP since 1997. Before many of you were born. This is old. It really isn't needed.
02-03-2023 7:13 AM
You are right, even in SAT the performance is lower (the test is not really perfect) :
DO 1000 TIMES.
SELECT SINGLE werks
FROM t001w
WHERE bwkey EQ '0200'
INTO @DATA(the_plant_of_matthew).
ENDDO.
DO 1000 TIMES.
SELECT werks
INTO @DATA(my_plant)
UP TO 1 ROWS
FROM t001w
WHERE bwkey EQ '0202'.
ENDSELECT.
ENDDO.
So we could definitively stop using this ENDSELECT statement
02-06-2023 8:54 AM
matthew.billingham I like to distinguish between select single when all key fields are specified in WHERE and up to 1 rows when only partial key is specified.
02-06-2023 12:39 PM
dominik-tylczynski That's the rationale of many people, but for existence checks which is how it is most often used, to me, it violates clean code principles. This just looks ugly and unnecessary:
SELECT abap_true INTO @DATA(it_exists) WHERE ... UP TO 1 ROWS.
ENDSELECT.
Further more, select single in these cases is supported (now, it didn't used to be) in the documentation:
If no unique row is identified, the addition SINGLE can also be used to detect whether a corresponding row exists.
Conceding that the warning must be hidden by a pragma.
02-07-2023 10:58 AM
matthew.billingham I understand your point. Still distinguishing between SELECT SINGLE and SELECT UP TO 1 ROWS shows that the developer knows what they are doing and know they are not specifying the full key. I prefer that this way and it doesn't look ugly to me. But De gustibus non est disputandum Also we are discussing tiny little detail of good coding practices. I'm sure both you and I have seen much more sever violations of clean code principles.
02-07-2023 1:15 PM
3a9e4ce873a94034b33dc62b0ce600ee
Oh yes, far worse!
But... https://www.explainxkcd.com/wiki/index.php/386:_Duty_Calls