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: 

SELECT/ENDSELECT S4HANA

former_member561296
Discoverer
0 Kudos

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.

11 REPLIES 11

FredericGirod
Active Contributor
0 Kudos

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

salah_zinet
Participant

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.

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

0 Kudos
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

matt
Active Contributor
0 Kudos

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.

matt
Active Contributor

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.

FredericGirod
Active Contributor
0 Kudos

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

DominikTylczyn
Active Contributor

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.

matt
Active Contributor

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.

DominikTylczyn
Active Contributor

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.

matt
Active Contributor

3a9e4ce873a94034b33dc62b0ce600ee

Oh yes, far worse!

But... https://www.explainxkcd.com/wiki/index.php/386:_Duty_Calls