HOW TO FIX WARNING "SELECT QUERY"

[anilkumar_raina]

I AM SELECTING 6 FIELDS FROM FEBEP TABLE INTO AN INTERNAL TABLE ,BUT THE PROBLEM IS THAT WHILE INSPECTING CODE I AM GETTING AN ERROR WARNING THAT FEBEP "TABLE IS TOO LARGE SPECIFY WHERE CONDITION".

HOW CAN I FIX THIS PROBLEM AS IT IS NOT POSSIBLE FOR ME TO SPECIFY WHERE CONDITION.

ANIL

[Former Member]

Hi,

You can try with field groups and cursors.

Field groups:

The concept of field groups is such that some of the existing fields, say in an internal table, could be logically grouped into an object. The Insert statement is used to determine which fields belong to a field group at runtime. A field group does not reserve storage space for the fields, but contains pointers to existing fields. When filling the extract dataset with records, these pointers determine the contents of the stored records. Data is written to the paging space instead of memory.

This method is good since it can hold a large number of records. On the other hand, the performance is an issue in this case. Moreover only limited number of operations can be performed while using the field groups. Also maintenance is an issue in this method. The advantage in this method is that the control commands, which we use with the usual internal tables, can be used. The entire dataset, which is extracted into a field group, can be sorted using ‘HEADER’. ‘HEADER’ is a field group again, which will contain those fields based on which the field group will be sorted

Example

FIELD_GROUPS: header, fg_table

INSERT: I_equi-equnr into HEADER.

INSERT:

i_equi-equnr i_equi-objnr I_equi-matnr

INTO fg_table.

SELECT equnr objnr matnr

INTO i_equi

FROM equi AS

EXTRACT fg_table.

Sort.

• Process the records.

LOOP.

AT NEW i_equi-matnr.

Write I_equi-matnr, I_equi-objnr.

ENDAT.

ENDLOOP.

ENDSELECT.

In the above example, the field I_equi-equnr has been inserted into header. As soon as the ‘Sort’ command is executed, the field group fg_table will be sorted based on the field equnr i.e equipment number.

USING CURSORS WHILE FETCHING THE DATA

Cursors are useful when large volumes of data have to be processed. Their utility could be appreciated only under such circumstances. The cursor definitely works better when we need to process millions of rows and are approaching close to the limits of "maximum memory allowed to one process”. The reason is that the command 'Fetch' does not transfer the whole processed data from database server to application server in single shot, but does it in small packets. The number of cursors that could be opened by a user is specified in the INITSID.ORA file in ORACLE. Cursors might slow down the performance of the program in certain cases.

In this method we are populating the cursors, which is a kind of internal table, which hold the data for processing. This approach is good since the cursors can hold good number of records.

Example

DATA: C TYPE CURSOR,

WA LIKE equi.

OPEN CURSOR C FOR SELECT * FROM equi

WHERE <Select condition>

ORDER BY PRIMARY KEY.

DO.

FETCH NEXT CURSOR C INTO WA.

IF SY-SUBRC <> 0.

CLOSE CURSOR C. EXIT.

ENDIF.

• Do something here

ENDDO.