Consider the following problem.
We are processing some data in SAP and need to retrieve the text of some domain fixed values (the texts are held on table DD07T). We know the name of the domain (we wrote the program after all) and we know the value. Also being good ABAP developers we want to write efficient, modular code.
To write database efficient code we should buffer the lookup data rather than read it each time from the database, and to make it modular we should put our data retrieval code in a subroutine.
Buffering the data is easy enough we just need an internal table which contains;
So, each time we need some domain texts we can call a subroutine which looks at the above internal table for our domain name and value and reads the text value. If it isnt there we can read the database and store the result in our internal table in case we need it next time.
But there is a problem, where do we declare our internal table? We can make it global, but being good programmers we know that global variables are bad practise. If the internal table is local to the subroutine it will be cleared each time the subroutine ends. We need some kind of halfway house whereby the internal table is local to our subroutine and retains its values for the lifetime of the program.
Luckily, ABAP has the keyword STATICS, which provides just this sort of functionality. Static variables are local to a subroutine but retain their values for the lifetime of the program. All we have to do is declare our internal table with the keyword STATICS rather than DATA and we now have an internal table which is not cleared when the subroutine ends but when the program finishes.
Right, enough theory lets have a look at a proper working example of a subroutine using only local and static variables to completely encapsulate the data.
FORM read_dd07t USING value(p_domain) TYPE domname value(p_code) TYPE domvalue_l CHANGING value(p_text) TYPE ddtext. * declare our working storgage TYPES: BEGIN OF t_dd07t, domain TYPE domname, code TYPE domvalue_l, text TYPE ddtext, END OF t_dd07t. DATA: l_index TYPE sytabix, wa_dd07t TYPE t_dd07t. * this is our internal table we are using as a buffer STATICS: itab_dd07t TYPE STANDARD TABLE OF t_dd07t. * check and see if we have retrieved this value before. READ TABLE itab_dd07tINTO wa_dd07t WITH KEY domain = p_domain code = p_code BINARY SEARCH. IF sy-subrc NE 0. * no so we need to read it from the database * sy-tabix holds the line in the internal table at which the data * would reside if it was there so we know where to place our value * when we find it. l_index = sy-tabix. * read the data from the database SELECT SINGLE domname domvalue_l ddtext INTO wa_dd07t FROM dd07t WHERE domname = p_domain AND ddlanguage = sy-langu AND as4local = 'A' AND as4vers = '0000' AND domvalue_l = p_code. IF sy-subrc = 0. * place it where it should go INSERT wa_dd07t INTO itab_dd07t INDEX l_index. ENDIF. ELSE. * possibly put in some default values to prevent * multiple hits on the database ENDIF. * return our found text p_text = wa_dd07t-text. ENDFORM.
Static variables provide a tidy solution to some particular problems, especially when it comes to buffering data. It is not a new concept (they were available in 4.0b) and one that I dont seem to see many ABAP developers use either.
There is one area where they cannot be used however, instance methods of classes, but you can use them in class methods.