Skip to Content

DATA definition: TYPE or ?

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.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

8 Answers

  • Apr 19 at 05:54 AM

    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. :-)

    Add comment
    10|10000 characters needed characters exceeded

  • Apr 19 at 12:41 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • 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.

  • Apr 19 at 04:07 PM

    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.
    Add comment
    10|10000 characters needed characters exceeded

    • 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!

  • Apr 19 at 07:03 AM

    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.

    Add comment
    10|10000 characters needed characters exceeded

    • 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. :)

  • Apr 19 at 05:37 AM

    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...)

    Add comment
    10|10000 characters needed characters exceeded

  • Apr 19 at 06:23 AM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • Apr 19 at 05:34 AM

    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.

    Add comment
    10|10000 characters needed characters exceeded

  • Apr 19 at 01:01 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

    • "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.