Clear Work Area and Internal Table in entire program

[Former Member]

Hi Experts,

I have some problem that i'm already solve it, my problem is about CLEARING working area and REFRESHING internal table. i found out after the program execute the internal table and working area are still cointain the data when the program executed for the second time, the first execution data will combine with the second execution.

im already create form that i used to clear all working area and refresh the internal table. but i think thats still not efficient. is there any function or procedure i can use to clear or refresh all working area and internal table in single or couple lines?

note: im already browse in google i havent found any.

Thank you in advance and sorry for my bad english 🙂

here the example of my code that i think its not efficient:

[retired_member]

Since you show only a subroutine, without telling anything about the environment (program type and execution, where is the subroutine called etc.), one can give only general hints:

You should make yourself knowledgable about

• internal tables with header lines (strongly dissuaded)

• program organization (execution of (external) subroutines, also dissuaded)

In order to understand your code better you should not use obsolete concepts. One of the reasons that they are obsolete is their strange behavior. REFRESH is obsolete too.

[Former Member]

For more information, my program type is Module Pool. The Subroutine will call first (in PBO) to Clear and Refresh all internal table and working area. after i read your reference i should change refresh into free but it still not efficient if i should write all working area and internal table i declare before in the subroutine. and there is a risk if the future enhancement to add more internal table and the programmer not add the internal table to the subroutine.

Thank you in advance.

[Sandra_Rossi]

You wouldn't have to bother if you used ABAP Objects, all these data objects as attributes of an object, and creating the object guarantees that these attributes have the initial value.

PS: using a module pool doesn't prevent using ABAP Objects on 99,99% of the code.

[matt]

I liked the fact that the FORM name begins with f_. obviously just in case, you know, you mistook it for an object reference...

[retired_member]

"and there is a risk if the future enhancement to add more internal table and the programmer not add the internal table to the subroutine."

If this is your concern, Sandra's answer is correct. Use ABAP Objects and let the garbage collector do the work for you.

[nomssi]

Hello Hariyanto Hariyanto,

your central FORM for all initialization works, it is generally a best practice to initialize variables before they are used. The problem is not efficiency as your implementation is fast enough, but

• others might not know about this policy and declare variables elsewhere
• it is easy to miss some variables when you recheck after each change
• there are no limit on how any other FORM/function may change the data

So a lot discipline is required from the developer. In a complex design, it is difficult to gain confidence that all variables are properly initialized. Sandra and Horst already proposed the solution: use the Create Object pattern of ABAP Objects

In its simplest form, you make all variables public attributes of a class. You now must create an object using the CREATE OBJECT obj statement to access those attributes without a run-time error. The attributes are all initialized automatically.

You might implement a CONSTRUCTOR method for explicit initialization. For a complex design many objects are needed, each with its own initialization. A special factory method or a separate factory class will give you confidence that all objects are properly initialized. With this approach, the system helps you enforce the initialization of your data (attributes) before usage.

Further, you can make the data private and so control with routine (method) is allowed to change the data. Those are basic but significant advantage of objects.

regards,

JNN

[Former Member]

Horst Keller is right about the concepts..

I think your subroutine is not getting called every time so not clearing workareas and internal tables.

If you want to get the root cause, better way would be put a breakpoint inside subroutine and then check if it is called or not?

Then yourself can find the issue, as this is clearly your program design issue.

And best way to clear workarea is 'Clear' and Internal table 'Free'(which you are already using).

[Rashid_Javed]

Can you share more details about your problem like

-Where in your code this FORM is called

-Is it under some IF statement (so it is called based on some condition)

-Did you debug it and verified if the code in Form is ecxecuted