The system relies on it's data, and data needs to be selected. SAP has implemented SQL (Structured Query Language) in it's ABAP to answer to the data selection requirement.
SELECT * FROM vbap WHERE ... in short, but check these articles for the longer versions.
The internal table is an Abap language component that is used very often. Whenever information is needed in repetitive form, the internal table is used. You will not find many reports that have no internal tables, and they have been around since the earliest Abap versions.
Processing an internal table is done in an Abap specific way. With internal tables, a work area is required. Actual changes are done on the fields in a work area, which can be appended (
APPEND) at the end of the internal table or inserted (
INSERT) at a given position (by specifying an index number). Since internal tables play such a big big role in Abap reporting, check out this article internal table specifics. Here's a listing of actions you can do to your internal table:
An internal table is very handy, but you may want a table with tables or "table-in-table". Which is no big deal at all. How are they defined, what to do about the message: "YOUR_TYPE" is a generic type. Use of this type is only possible for typing field symbols and formal parameters.". Some examples:
SELECT statement is kind of a big deal in ABAP programming. SAP sits on a database server and the
SELECT statement serves data into ABAP. It's is the main and only channel in fetching data, so it is good to know a thing or 2 about it. In it's simplest form:
TABLES: mara. SELECT-OPTIONS:
so_matnr for mara-matnr. SELECT * FROM mara WHERE matnr IN so_matnr. * Do something with the result ENDSELECT.
The above example selects all available fields (
*) from table
mara (The material master) for which the material number (
matnr) is specified in range variabele (select-options variabele)
so_matnr. Note that the actual select statement is a loop, ending with
JOIN addition on
SELECT allows you to merge several data tables together into a single result or result table (mostly). As database servers are quite clever bits of machinery, using a join is not only nice coding, it can be very helpful in a good performance too.
A simple example:
SELECT hdr~vbeln itm~posnr
itm~matnr FROM vbuk AS hdr INNER JOIN vbup AS itm ON hdr~vbeln = itm~vbeln INTO TABLE gt_results WHERE hdr~vbeln in so_vbeln.
JOIN is used, the soul purpose wil be involving multiple tables in a single select action. The result will most likely be an internal table with columns from several tables. You can set up your internal table with fieldnames that do not match the fieldname in the original table - see the example:
This is not very common, but in some cases table structures can hold a repetition of values in a single row. Thus a record from the transparent table holds columns with similar information. An example would be from HR: table
PA0008 also known as Infotype 8. This table has fields called
LGA01, LGA02, LGA03 ... LGA40 The
VARYING option on the
DO .. ENDDO statement can be a great help here.
SELECT statement can also be used in a dynamic way. The list of fields, the actual
WHERE clause and the table name can all be defined at runtime. This is not very common and maybe even difficult to read (for your fellow developers) but it is a powerful option that you do need to know about. If not to implement yourself, this article can clarify how dynamic selects work.
If your report/program does not select data, it's development is probably not finished. If your programs selects great amounts of data, it will probably be slow in performance. Other than making sure the data itself is selected efficiently (check the articles on performance tuning) there is another fact on data selection. Whenever a selection is done, a communication channel to the database server is opened, the request is "handed over" and the results are received. That's quite a suite of actions, which are all taken care of by the system.
Know this: if you scatter selection logic all over your report, the communication channel will close or fall asleep. A few nano seconds later your new request comes in and the system will need to wake up, have some tea, start up connections and get the show on the road again. All of this is consuming valuable performance time. Thus: select all you need and work with what was selected. Ideally.