DATA definition: TYPE or ?

[Jelena]

Was hoping to find some guidelines on this but didn't see any specific suggestions.

When you define variables, do you use a data element or table and field name as type? For example:

DATA: lv_werks TYPE vbap-werks.

or

DATA: lv_werks type werks_d ?

(And it always gets me that WERKS is a structure. 🙂 )

I lean towards the first option, especially when defining internal tables for SELECT. Obviously SAP can change the assigned data element in a standard table, so reference like vbap-werks prevents from a possible type error. But I'm wondering if there are any other factors to consider. What do you use and why?

Thank you.

[teejay]

Interesting question Jelena 🙂

I have used both. At one of client's development standards it was actually mentioned to use underlying data element instead of table fields.. (Maybe table field creates additional overhead ?)

But practically speaking, In my opinion only major difference it would make is in where used results, if you want to reverse lookup in what all programs a particular table field is being referenced.

Looking forward to other answers !

Regards,

Tarun

[Jelena]

Good point on "where used", I haven't thought about it. Our guidelines didn't have any rules on that (well, they were written by me and I have no clue, as you see 🙂 ). But I'm also wondering if some kind of overhead could be involved. And I agree, it's really minor thing but I just realized I do something and I don't even know why.

[UweFetzer_se38]

In the past I've always used data elements. But don't ask me why. Maybe simply because it's shorter.

Nowadays, of course ;), I'm only using inline declarations.

[fabianlupa]

I mostly use the data element directly as it's more obvious to me what the type is. The only exception is when I define an output table type for an ALV, because in my experience using the structure works better for value helps in generated field catalogs.

The argument of the data element changing in the structure definition works in both ways by the way. Maybe your code only works if the type does not change when the structure changes, depending on the use case (other than select propably).

(Also using the structure in the type definition introduces an additional hard dependency on the structure type which might be less visible than the data element especially if it's the structure of a database table. That is if you are using package interfaces...)

[matt]

Looks like someone screwed up early with structure WERKS and it was too late to do anything about it afterwards!

I use the second. Irrational I know, but I just don't "like" the first. However, semantically

DATA werks TYPE vbap-werks.

has more contextual meaning than

DATA werks type werks_d.

If the variable is only used in the context of the sales document item plant, then you should probably use the first, but call the variable sales_doc_item_plant (although I think we can be forgiven using werks instead of plant, since werks is so widely understood). I guess the idea is that if for some utterly strange reason, a VBAP plant became a different thing from a MARC plant, your program is safe.

If the meaning is more it just being the plant, then use the second. All very minor stuff and I don't think it really matters (obviously, because I prefer the "wrong" one). Of course

SELECT SINGLE werks FROM vbap INTO @data(sales_doc_item_plant) WHERE ...

does away with the whole problem. 🙂

[pokrakam]

I also believe in using the simplest (read: most elementary) option. So it's data element for me too.

Like others, I tend to go for inline declarations too.

I disagree with Tarun's argument about where-used, IMHO this unnecessarily narrows the scope. Within the same component one developer may reference VBAP-WERKS and another T001W-WERKS instead - after all this is the origin of Plant.

So data element is both more concise and more generic.

[former_member539238]

I got a question regarding your answer, when we use the reference to table fields, if the same table field is the source of the data, then later on if the table field changes then we don't have to change the types in all the reports or programs where that table fields is used.

For example I have a custom table YTEST_TABLE with field TEST_FIELD of data element INT4.

Now if I use INT4 directly in the programs to use the data, then if later I change INT4 to NUMC then I have to change the value everywhere the field is used. Instead if I refer the table field I don't have this problem.

So is it not better to use reference?

[pokrakam]

That's what Domains are for.

[Jelena]

What really grinds my gears is when definition is t001w-werks but then the variable is filled from VBAP or MARC and T001W is not even mentioned anywhere else.

[pokrakam]

...another reason for using the elementary definition 🙂

[SimoneMilesi]

i admit i use the first option when i do not remember the data element, so i refer my variable to a table's field, otherwise i refer to the basic data element.

i know, i'm lazy.

[Jelena]

Sometimes I find myself doing the same. After getting burned a few times (like with WERKS) when "owls are not what they seem", I started to prefer <table-field> option just to avoid any issues. But when it's a more generic variable then I look for a data element. I guess that makes sense... At least that's what I'm telling myself. 🙂

[joao_sousa2]

You shouldn’t be making SELECTs to standard tabels anyway . Use the standard API!

In the end of the day SAP may decide to change the table itself , and making direct selects will break your code in an upgrade.

[SimoneMilesi]

Tell me when the APIs are all well developed so i start to switch and change my code... if i'm not retired yet 😄

[kiran_k8]

"You shouldn’t be making SELECTs to standard tabels anyway . Use the standard API!

In the end of the day SAP may decide to change the table itself , and making direct selects will break your code in an upgrade."

I am hearing such a comment for the first time. Is it really possible to use API everytime instead of Selects on DB ?

Surprising and a bit difficult to comprehend what could be the underlying motive of this approach.

K.Kiran.

[ŁukaszPęgiel]

1) Whenever I create a report or transaction that suppose to work with the existing or standard objects (sales orders, purchase requisitions, etc. ) then I always use the reference to table and field specific to the development, so for sales orders vbap-werks, for purchase orders eban-werks and so on. The reason behind is that then I'm sure that when I will link this field to a screen field or to ALV then I will have correct F1/F4 help, input help and translation.

2) When I create new objects then I use two ways:

• If I have a Z-table behind, then I do the same like in point 1) but instead of using standard Data Elements I create often new ones, for better translation for example.
• In case I don't store anything in DB but I just do some functions then I create a type or structure inside FG or class and later on I reference the type stored there, for example data: plant type zcl_whatever=>t_data-plant. In this case whenever I need change I do it only in one place.
  Of course if I would need to display this field somewhere then I would create data element first and I would reference it inside the class / FG.

[Jelena]

Thanks for a reply! This sounds like my approach as well. I don't have any reasonable explanation for it though, 🙂 But it looks like there is really no "right" or "wrong" way of doing it in general, just different situations and personal preferences.

Well, either way this has been an educational thread for me. Thanks for sharing!