To Create Workarea for Ranges

[Former Member]

Hi ,

How to create Workarea for Ranges?

e.g  data : r_prdha TYPE RANGE OF mara-prdha,

                w_prdha LIKE LINE OF r_prdha.

Here , I donot want to use ' LIKE LINE OF ', Is there any other way for the declaration of Workarea .

Regards,

Raghu

[former_member339717]

Dear Raghu singal,

THE BELOW STATMENT WILL CREATE A RANGE FOR YOU BUT WILL NOT DISPLAY ON THE SELECTION SCREEN.

DO YOU HAVE A PROBLEM WITH THE CAPS LOCK BUTTON OF YOUR KEYBOARD?

There is no need to create the work area you can use it directly.

SELECT-OPTION: R_PRDHA FOR MARA-PRDHA NO-DISPLAY.

r_prdha-sign = 'I'.

r_prdha-option = 'EQ'.

R_PRHDHA-LOW = '1000100'.

R_PRDHA-HIGH = '10001000'.

APPEND R_PRDHA.

CLEAR: R_PRDHA.

Message was edited by: Suhas Saha

[Former Member]

Hi ,

My question is just to make a Workarea of r_prdha,without using LIKE LINE OF. I am able to create range.

[Former Member]

Hi Raghu,

Ranges are like select-options but we con't see those in selection screen.

Once you create the ranges for ex: r_prdha it itself is a work area which contains SIGN,OPTION,LOW and HIGH Fields.

it's behaves like a internal table with header line.

R_PRDHA    ----------  is work area

R_PRDHA[]  ----------  is initernal table.

I think you need not to create work area again.

Thanks

Mani

[former_member339717]

Rghu no need to create area it will work like header line.

Regards,

[former_member339717]

This message was moderated.

[matt]

Zahid Hameed wrote:
Dear Raghu singal,
There is no need to create the work area you can use it directly.
SELECT-OPTION: R_PRDHA FOR MARA-PRDHA NO-DISPLAY.
r_prdha-sign = 'I'.
r_prdha-option = 'EQ'.
R_PRHDHA-LOW = '1000100'.
R_PRDHA-HIGH = '10001000'.
APPEND R_PRDHA.
CLEAR: R_PRDHA.

You can but it is creating an internal table with a header line which is obsolete BAD programming. Sure, we have to use the things sometimes (as selection options!), but we certainly shouldn't when don't have to.

[Former Member]

Why don't you try with select options.

[Former Member]

Hi ,

I tried with the Select options,but while appending the data into range , it is coming as error in Extended Program check in Obsolete statement category.

[Former Member]

Then, to avoid that error, direct refer to the Data  Element of the field which you want to refer and accordingly you can  adjust your Parameter declaration.

[former_member188219]

data: lr_vkorg TYPE RANGE_VKORG_TAB.

just find the range table and declare accordingly

[Former Member]

   DATA : R_PRDHA TYPE RANGE OF MARA-PRDHA,
       W_PRDHA TYPE SMB_UIE_PRODH_RANGE_LT.

[former_member195402]

Hi,

to avoid internal tables with header lines as created with RANGES or SELECT-OPTIONS you have either to define a local range type in your program or a DDIC structure.

A local type definition may be

TYPES: BEGIN OF x_prdha,

         sign   TYPE bapisign,

         option TYPE bapioption,

         low    TYPE prodh_d,

         high   TYPE prodh_d,

       END   OF x_prdha.

Then you can define your workarea TYPE x_prdha.

Alternatively you can create a DDIC structure or search for an existing DDIC structure, looking at the where-used-list for the data element of the table field in structures. Search the result list for fieldname LOW.

In our departments development rules the usage of LIKE or LIKE LINE OF is forbidden, too.

Regards,

Klaus

[sivaganesh_krishnan]

Hi Raghu,

you can create a select - option instead of creating a work area of ranges. Select-option will do the job.

[matt]

The select-option solution is bad programming.

[former_member339717]

Mathew Blingham,

Can you explain what is the difference between range and select-option and why it is a bad programing? I really want to know about it?

[matt]

A select option is an internal table with a header line. Something declared as RANGE OF is an internal table without a header line.

The problem with a table with a header line is that it is ambiguous. Ambiguity in programming is fairly universally recognised as bad. When you see it in a program, you don't know if it is referring to the internal table itself or its header line.

So

selopt-low = 5. " Here selopt refers to the header line

loop at selopt. " Here selopt refers to the table

clear selopt. " Here selopt refers to the header line

The point is, you have to decide, according to the context, whether selopt is the header line or the internal table. This problem is the basic problem of all internal tables with header lines and why they are obsolete.

Of course, we cannot avoid using select options in programs where we need the user input. But everywhere else, we should avoid tables with header lines. A second principle of programming is that you should define exactly what you need. Subverting a select option to use as a range violates this principle. Hence, if you need a range - define a range. If you need a range work area, and some idiot development manager has decided LIKE is bad, then use TYPEs as detailed above.

[former_member188251]

Good one  Matthew !

[former_member339717]

Then why they use like statments in decalaring the variables in the Bapis? any reasons for using likes in bapi. against the table type? and I have been using with header line but I haven't had any difficulties for last five years or so. I have read in the manuals that you can use it but it is better not to use it. But I have no bad experience with it. When ever I need a new structure I declare it with type.

[matt]

Some people have no problem naming their internal tables itab1, itab2, itab3. It doesn't mean it's right. If you want to continue using obsolete and lower quality statements - feel free. It would count against you if I were to interview you for a role

Sometimes to work with badly designed/older parts of SAP, like older bapis you may also need to use tables with headerlines. The point is avoid it wherever possible. Declaring a selection option because you want a range is bad programming. It's like declaring a variable as type F when you're dealing with monetary amounts. It'll work, but it isn't good.

[former_member339717]

Thnx Matthew Billingham,

            For valuable anwers. I will try to make a habit of using types instead of likes. But my question is still there if the like statement is not a good programing technique then why are they using it in bapis, any particular reason. Now i will name a bapi which is new one bapi_po_getdtail1 if you go to its table area the programer has declare all the variable wih like statement. If it is obsolete then why they have been using it in new  bapi's . I just wana clearify my self that's it.

regards,

[matt]

mmm - I think you've misunderstood. Using a select option instead of a range is bad. Using internal tables where avoidable is bad. Using LIKE is fine.

Using like when appropriate is not a problem. It is the OP's development manager who has decided that it is. I do not agree with him.

LIKE is perfectly acceptable programming.

[former_member339717]

Dear Matthew,

• I think the sap is totaly moving towards object oriented. In my opinion in conventional programing we can use the header line, but when you will be going to develop objects, using OOPS. It will not allowing you to create tables with header line. That is the only reason in my opinion that they have been obsoleting it. If I m wrong please correct me.

[SuhaSaha]

In my opinion in conventional programing we can use the header line

I have been working on "conventional programming" from 2005 & internal table with header lines have been obsolete since then.

Due to backward compatibility SAP cannot do away with internal tables with header lines & it still remains for us to use.

I have been using with header line but I haven't had any difficulties for last five years or so

Do you not run the code inspector/SLIN checks on your programs? If yes, do you not take any action on the error/warning messages?

BR,

Suhas

[matt]

You've got it the wrong way round. OOPS doesn't allow you to use tables with header lines precisely because they are bad programming concepts.

SAP mark certain programming constructs as obsolete in procedural code because it is bad programming (they can't fix all the code that uses these things, so marking the constructs as obsolete = do not use, is the next best thing). They prevent you using them in OOPS because they are bad programming.

[former_member339717]

Matthew,

            That's what I mean , I have been using it in conventional programming not in OOPS. Thnx for the valuable answers. I will not use the Header line any more and will try to avoid  use of header and try to use type instead of likes. thank you very much.

[former_member339717]

Thnx suhas,

I will try this, Thnx for your output.

regards,

[matt]

Yes. And using it within conventional programming is bad.

LIKE, however, is not bad programming, and so you do not need to avoid it.

[Former Member]

If we declare range using statement:

   RANGES : R_PRDHA FOR MARA-PRDHA.

then it creates a headerline also.

But RANGES keyword is obsolete and is not allowed in classes.

So,we have to declare ranges as Raghu has declared.

data : r_prdha TYPE RANGE OF mara-prdha

And this statement will not create a header line so we have to declare workarea seperately.

[raymond_giuseppi]

Did you try this kind of syntax :

TYPES: type_range TYPE RANGE OF matnr.
 DATA: itab_range TYPE type_range.
 FIELD-SYMBOLS: <range> TYPE LINE OF type_range.
 
 APPEND INITIAL LINE TO itab_range ASSIGNING <range>.
 <range>-sign = 'I'.
 <range>-option = 'EQ'.
 <range>-low = 'XXXXXX'.

Regards,

Raymond

PS : No LIKE statement were harmed during the making of this post.

PPS : No work area either

[SuhaSaha]

Another instance of people not validating their response before posting it, sigh

[raymond_giuseppi]

?

[SuhaSaha]

I think you got it wrong

I was talking about other persons' responses, yours is 100% correct!

[raymond_giuseppi]

Okay, no problem

[former_member188251]

Nice solution Raymond !

[Former Member]

Hi,

you can try to use a SET transaction GS01 (Create).

Cheers

Ivan

[Pawan_Kesari]

TYPES : tr_prd TYPE RANGE OF mara-prdha ,
         ty_prd TYPE LINE  OF tr_prd     .

DATA : r_prdha TYPE tr_prd,
        w_prdha TYPE ty_prd.

[Former Member]

Thanks Pawan

[ThomasZloch]

Why your antipathy towards "LIKE LINE OF"? It's a standard way of doing this following a TYPE RANGE OF declaration.

Sounds like another constructed "how to sort my internal table without using SORT statement" type of question, or please explain the background.

Thomas

[SuhaSaha]

Why your antipathy towards "LIKE LINE OF"? It's a standard way of doing this following a TYPE RANGE OF declaration.

QA reviewer (smart *** tone): "Usage of LIKE in data declaration, please change it. "

TZ/Suhas (angry tone): "But it's a standard way of doing this following a TYPE RANGE OF declaration "

QA reviewer (confused tone): "But it's there in the QA review checklist . I just follow what's there in it."

TZ/Suhas: "But the checklist also says use parallel cursor for nested LOOPs. To hell with your checklist "

QA reviewer (sulking): "Excuse me, then how do you optimise nested LOOPs? The runtime will increase exponentially (trying to show his smartness again)"

TZ/Suhas: "Heard about SORTED tables? Read Hermann/Siegfried's blogs on SCN"

Cheers,

Suhas