abap

[Former Member]

In Bdc session Methoid lakhs of records is there.I had upload the data.At that time 50000 thousand records uploaded remain 50000 thousand error records is there.I had find out sm35.How to download the error records.anybody send me h to processs that one

2.What are the Rangestables?

3.WhaT PURPOSE to use readtable?

[Former Member]

Hi,

If u r using session method. Automatically logifle will be created.

u can see that logfile and it's contents from SM35 itself.

U will be having pushbutton for that under the menubar.

Rewardpoints if useful.

Regards

(YUGANDHAR.P)

[Former Member]

When u use session method we can see that in sm35 itself..When u use transaction method means u want to use the bdcmsgcoll structure...

Using the structure u wnt to create an internal table and the logs are stored in the internal table..u can use format_message function module

[Former Member]

in sm35 transaction u will SELECT U R SESSION AND GOTO UTILITIES TAB ...U WILL FIND EXPORT SESSION ...........GIVE THE FILE PATH NAME THERE .....AND STANDARD SAP WILL TAKE CARE OF DOWN LOADING THE ERROR FILES TO DESKTOP......

RANGES tables

You can use the following variants of the TYPES and DATA statements to create internal tables of the same type as selection tables.

TYPES|DATA <rangetab> TYPE RANGE OF <type>.

or

TYPES|DATA <rangetab> LIKE RANGE OF <obj>.

This defines internal standard tables whose line type is a structure as follows:

SIGN(1) TYPE C

OPTION(2) TYPE C

LOW TYPE <type> bzw. LIKE <obj>

HIGH TYPE <type> bzw. LIKE <obj>

You can also use the RANGES statement to create internal tables of the same type as selection tables.

RANGES <rangetab> FOR <f>.

This statement is simply a shortened form of the following statements:

DATA: BEGIN OF <rangetab> OCCURS 0,

sign(1) TYPE c,

option(2) TYPE c,

low LIKE <f>,

high LIKE <f>,

END OF <rangetab>.

Because the statement represents an obsolete form of defining internal tables with headers and headers should not to be used, you should use above variants of TYPES and DATA statements instead of RANGES.

Tables defined in this way have the same structure as selection tables, but they do not have the same functionality. They are not part of the selection screen: No corresponding input fields are generated and these tables cannot be used as a data interface in a program <prog> called using

SUBMIT <prog> WITH <rangetab> IN <table>.

. However, you can use the above statements to create the table <table> in the calling program. The main function of these tables is to pass data to the actual selection tables without displaying the selection screen when executable programs are called.

The above tables are like actual selection tables in the WHERE clause of Open SQL statements and can be used in combination with the IN operator in logical expressions, but they are not linked to a database table. They:

are not passed like selection criteria to logical databases

cannot be used with the shortened form of selection tables in logical expressions

cannot be used like selection criteria in GET events

Obsolete version:

REPORT demo_sel_screen_tables_ranges.

RANGES s_carrid1 FOR spfli-carrid.

s_carrid1-sign = 'I'.

s_carrid1-option = 'EQ'.

s_carrid1-low = 'LH'.

APPEND s_carrid1.

SUBMIT demo_selection_screen_ldb_1 WITH carrid IN s_carrid1

VIA SELECTION-SCREEN AND RETURN.

Korrekte Version:

REPORT demo_sel_screen_tables_ranges.

DATA: s_carrid2 TYPE RANGE OF spfli-carrid,

s_carrid2_wa LIKE LINE OF s_carrid2.

s_carrid2_wa-sign = 'I'.

s_carrid2_wa-option = 'EQ'.

s_carrid2_wa-low = 'AA'.

APPEND s_carrid2_wa TO s_carrid2.

SUBMIT demo_selection_screen_ldb_1 WITH carrid IN s_carrid2

VIA SELECTION-SCREEN AND RETURN.

A selection table S_CARRID is created with reference to column CARRID of database table SPFLI. Fields S_CARRID-LOW and S_CARRID-HIGH have the same type as CARRID. The work area of the internal table S_CARRID is filled and appended to the table. Program DEMO2 is called. If DEMO2 is linked to logical database F1S, its selections screen contains the fields of selection criterion CARRID from the logical database. These fields are filled with the contents of the internal table.

Reading Lines of Tables

To read a single line of any table, use the statement:

READ TABLE <itab> <key> <result>.

For the statement to be valid for any kind of table, you must specify the entry using the key and not the index. You specify the key in the <key> part of the statement. The <result> part can specify a further processing option for the line that is retrieved.

If the system finds an entry, it sets SY-SUBRC to zero, if not, it takes the value 4, as long as it is not influenced by one of the possible additions. If the internal table is an index table, SY-TABIX is set to the index of the line retrieved. If the table has a non-unique key and there are duplicate entries, the first entry is read.

Specifying the Search Key

The search key may be either the table key or another key.

Using the Table Key

To use the table key of <itab> as a search key, enter <key> as follows:

READ TABLE <itab> FROM <wa> <result>.

or as follows

READ TABLE <itab> WITH TABLE KEY <k1> = <f 1> ... <k n> = <f n> <result>.

In the first case, <wa> must be a work area compatible with the line type of <itab>. The values of the key fields are taken from the corresponding components of the work area.

In the second case, you have to supply the values of each key field explicitly. If you do not know the name of one of the key fields until runtime, you can specify it as the content of a field <n i > using the form (<n i >) = <f i >. If the data types of <f i > are not compatible with the key fields, the system converts them.

The system searches for the relevant lines as follows:

Standard tables

Linear search, where the runtime is in linear relation to the number of table entries.

Sorted tables

Binary search, where the runtime is in logarithmic relation to the number of table entries.

Hashed tables

The entry is found using the hash algorithm of the internal table. The runtime is independent of the number of table entries.

Using a Different Search Key

To use a key other than the table key as a search key, enter <key> as follows:

READ TABLE <itab> WITH KEY = <f> <result>.

or as follows

READ TABLE <itab> WITH KEY <k1> = <f1> ... <k n> = <f n> <result>.

In the first case, the whole line of the internal table is used as the search key. The contents of the entire table line are compared with the contents of field <f>. If <f> is not compatible with the line type of the table, the value is converted into the line type. The search key allows you to find entries in internal tables that do not have a structured line type, that is, where the line is a single field or an internal table type.

In the second case, the search key can consist of any of the table fields <k 1 >...<k n >. If you do not know the name of one of the components until runtime, you can specify it as the content of a field <n i > using the form (<n i >) = <f i >. If <n i > is empty when the statement is executed, the search field is ignored. If the data types of <f i > are not compatible with the components in the internal table, the system converts them. You can restrict the search to partial fields by specifying offset and length.

The search is linear for all table types. The runtime is in linear relation to the number of table lines.

Specifying the Extra Processing Option

You can specify an option that specifies what the system does with the table entry that it finds.

Using a Work Area

You can write the table entry read from the table into a work area by specifying <result> as follows:

READ TABLE <itab> <key> INTO <wa> [COMPARING <f1> <f 2> ...

|ALL FIELDS]

[TRANSPORTING <f1> <f 2> ...

|ALL FIELDS

|NO FIELDS].

If you do not use the additions COMPARING or TRANSPORTING, the contents of the table line must be convertible into the data type of the work area <wa>. If you specify COMPARING or TRANSPORTING, the line type and work area must be compatible. You should always use a work area that is compatible with the line type of the relevant internal table.

If you use the COMPARING addition, the specified table fields <f i > of the structured line type are compared with the corresponding fields of the work area before being transported. If you use the ALL FIELDS option, the system compares all components. If the system finds an entry with the specified key <key> and if the contents of the compared fields are the same, SY-SUBRC is set to 0. If the contents of the compared fields are not the same, it returns the value 2. If the system cannot find an entry, SY-SUBRC is set to 4. If the system finds an entry, it copies it into the target work area regardless of the result of the comparison.

If you use the TRANSPORTING addition, you can specify the table fields of the structured line type that you want to transport into the work area. If you specify ALL FIELDS without TRANSPORTING, the contents of all of the fields are transported. If you specify NO FIELDS, no fields are transported. In the latter case, the READ statement only fills the system fields SY-SUBRC and SY-TABIX. Specifying the work area <wa> with TRANSPORTING NO FIELDS is unnecessary, and should be omitted.

In both additions, you can specify a field <f i > dynamically as the contents of a field <n i > in the form (<n i >). If <n i > is empty when the statement is executed, it is ignored. You can restrict the search to partial fields by specifying offset and length.

REWARD POINTS IF HELPFUL