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

ABAP code for multiple releases

phil_soady
Participant
0 Likes
4,169

Im hoping someone has an idea or solution to a one major issues and a few minor issues relating to language differences across releases.

Key pain point is the syntax for select and joins.

since 7.20 ?  and actual 7.40 select joins require variables  to be escaped with @

in 7.00 and earlier this syntax is not supported.

How can you write code that runs in all versions from 7.00

I could live with no support for 6.40 and lower. But 7.00 support is a must.

The cost and effort of maintaining multiple development systems is significant.

I can accept not using   string =   string && string

and sticking to concatenate s1 s2 into s3.

But the outcome with SELECT syntax  means we can not use joins at all.

Anybody know a solution to the SELECT join syntax that works in 7.00 and 7.40 ?

ABAP Keyword Documentation      ( simple mode )

and now

ABAP Keyword Documentation   (7.40  strict mode)

Can strict be disabled ?

Can you a version of code for difference Syntax compilers / release ?

How do you deal with release level inconsistencies in the language ?

1 ACCEPTED SOLUTION
Read only

matt
Active Contributor
2,543

Method 1.

Classes. Have a subclass one with the 7.00 syntax, one with the 7.40. Instantiate the appropriate subclass at runt time according to release. In 7.00, the 7.40 will be syntactically incorrect and vice versa, but it won't matter as it's never called.

Drawback - transports will always be red on import.

Method 2.

Macros. Encapsulate your release sensitive statements in DEFINE statements.


Drawback - well... it's macros!

Programmatically, I prefer method 1. Pragmatically method 2 seems the only solution.

However, 7.40 select joins require variables  to be escaped with @ I understood that 7.40 allows you to do this, and will perform a strict syntax check if you don't, but doesn't require it. Can you give me an example as I'm actually not that familiar with the new 7.40 stuff. (Only just got my sticky mitts on it).

11 REPLIES 11
Read only

matt
Active Contributor
2,544

Method 1.

Classes. Have a subclass one with the 7.00 syntax, one with the 7.40. Instantiate the appropriate subclass at runt time according to release. In 7.00, the 7.40 will be syntactically incorrect and vice versa, but it won't matter as it's never called.

Drawback - transports will always be red on import.

Method 2.

Macros. Encapsulate your release sensitive statements in DEFINE statements.


Drawback - well... it's macros!

Programmatically, I prefer method 1. Pragmatically method 2 seems the only solution.

However, 7.40 select joins require variables  to be escaped with @ I understood that 7.40 allows you to do this, and will perform a strict syntax check if you don't, but doesn't require it. Can you give me an example as I'm actually not that familiar with the new 7.40 stuff. (Only just got my sticky mitts on it).

Read only

0 Likes
2,543

SELECT  FROM /axo/mc_cust_002 AS c2 INNER JOIN /axo/mc_cust_001 AS c1

                                              ON c2~scenario = c1~scenario

                                        RIGHT OUTER JOIN /axo/mc_ct_001 AS c1t

                                              ON c2~scenario = c1t~scenario

                                              AND   c1t~spras l_spras

                  INTO CORRESPONDING FIELDS OF TABLE rt_user_scenario

                  WHERE c2~mobileuser = l_mobileuser

                  and   c1~scenario = l_scenario.

I get the following error without @ on the variables

If the new OpenSQL syntax is used, it must be used throughout. This includes using @ to escape host variables.

Read only

2,543

I like the multiple class idea. Im going to use that. 

The macro table and its big brother define are nasty. So I want use them.

getting customers used to seeing imports failed based on version is the only challenge.

But i will label them accordingly.

Note we only have a 1 dev system 7.40.   So the fact SAP doesnt allow you to code for and check for older releases is a big pain. 

The fact syntax on changed in unit test classes really hurts too.

Read only

0 Likes
2,543

Hi,

Can you take an example and share a code for it?

Thanks,

Kiran

Read only

SuhaSaha
Product and Topic Expert
Product and Topic Expert
2,543

Hi Phil,

and actual 7.40 select joins require variables  to be escaped with @

AFAIK, it is not necessary to do so; unless you wanna use the new open-SQL goodies. You can still happily write your open-SQL in the old way and the compiler won't complain (not sure if you get warnings, because i always use the new construct now ).


I could live with no support for 6.40 and lower. But 7.00 support is a must.

The cost and effort of maintaining multiple development systems is significant.

You should then build your product in the lowest BASIS release supported by it. In your case that would be 700.

There's always going to be a problem if you build your product in a higher release and then try to backport it to lower versions.

BR,

Suhas

Read only

matt
Active Contributor
0 Likes
2,543

Suhas Saha wrote:

There's always going to be a problem if you build your in a higher release and then try to backport it to lower versions.

BR,

Suhas

I've encountered this with persistence classes. If you generate a class in 7.3 using specific query options, and then transport to a 7.02 system, you get syntax errors. If you generate the class directly in the 7.02 system it works fine! The classes are generated slightly differently in the two systems.

Read only

SuhaSaha
Product and Topic Expert
Product and Topic Expert
0 Likes
2,543

Thanks for the info, i was not aware of it.

Anyway i have a feeling that SAP changes how certain objects are generated internally. Some of which are documented (e.g., re-organisation of class-pool includes with 731) and most of them are not(e.g., generation of the actors of persistence classes). In any case, if your code depends on some generated objects then you must be careful.

Off topic, but IMO worth mentioning -

Last week i wanted to create an overwrite-exit method for a class belonging to an SAP Add-on and i got the error - "The class has not yet been converted to the new class-local types" ... This is apparently due to the reorg of the class-pool includes and fixing it meant i must "modify" the class. Had to stick with explicit enhancements

Read only

0 Likes
2,543

What are the new SQL goodies?   Im just coding SQL

I dont see anything particular new about it.

How code I change this to make it old ?


SELECT  FROM /axo/mc_cust_002 AS c2 INNER JOIN /axo/mc_cust_001 AS c1

                                              ON c2~scenario = c1~scenario

                                       right OUTER JOIN /axo/mc_ct_001 AS c1t

                                              ON c2~scenario = c1t~scenario

                                              AND   c1t~spras l_spras

                  INTO CORRESPONDING FIELDS OF TABLE rt_user_scenario

                  WHERE c2~mobileuser = l_mobileuser

and   c1~scenario = l_scenario.



ERROR


If the new OpenSQL syntax is used, it must be used throughout. This includes using @ to escape host variables.

Read only

matt
Active Contributor
0 Likes
2,543

RIGHT OUTER JOIN - 7.40, SP05

Read only

0 Likes
2,543

Okay a left outer join works SOMETIMES without @.


SELECT  FROM /axo/mc_cust_002 AS c2 INNER JOIN /axo/mc_cust_001 AS c1

                                              ON c2~scenario = c1~scenario

                                         left OUTER JOIN /axo/mc_ct_001 AS c1t

                                              ON c2~scenario = c1t~scenario

                                              AND   c1t~spras l_spras

                  INTO CORRESPONDING FIELDS OF TABLE rt_user_scenario

                  WHERE c2~mobileuser = l_mobileuser

                  and   c1~scenario = l_scenario

                  and c1t~description = l_var.  " without this line it is ok without @



But you have made the point clear.  Thank you.


AVOID  the new features and all the WHERE conditions, field selections etc listed here

ABAP Keyword Documentation

then im ok.

Appreciate the feedback.  Very helpful.

Read only

0 Likes
2,543

There have been a few changes, like pragmas, unit test syntax etc that have caused me a bunch of pain.