nested loops, sorted table, hash table

[matthias_kasig2]

Hi,

I am facing a long-runner...

I've got this code:

TYPES: BEGIN OF ty_zkat,
         matnr(20) TYPE c,
         kurztext TYPE zkatalog_add-kurztext,
         langtext TYPE zkatalog_add-langtext,
       END OF ty_zkat.
DATA: ig_kat TYPE SORTED TABLE OF ty_zkat WITH UNIQUE KEY matnr,
      wg_kat TYPE ty_zkat.
 
LOOP AT ig_kat INTO wg_kat.
    LOOP AT ig_data INTO wg_data.
      IF wg_kat-kurztext CS wg_data-zl_artnr
      OR wg_kat-langtext CS wg_data-zl_artnr.
        wg_data1 = wg_data.
        wg_data1-treffer = 'X'.
        wg_data1-sapnr = wg_kat-matnr.
        APPEND wg_data1 TO ig_data1.
      ENDIF.
    ENDLOOP.
    CLEAR: wg_data1, wg_data.
  ENDLOOP.

ig_kat carries 35000 entries, ig_data in the inner loop about 5000.

the point is, that i need to compare with 'CS' (contains string)

so i have to look at <i>wg_kat-kurztext</i>, which might contain <i>'abcdefg'</i>, and have to find <i>wg_data-zl_artnr</i>, which might contain <i>'cdef'</i>.

I'd rather fancy doing this in one go, in one big select like:

select field1 field2 field3 from dbtab
  into ig_kat
for all entries in ig_data
  where field1 <b>CS</b> ig_data-zl_artnr.

Is such a CS string-comparison available in SQL?

Can I get better responses with a hash-table instead of sorted table?

help appreciated,

thanx, matthias

[Former Member]

CS for sql is <b>LIKE 'abcd%'</b>

[matthias_kasig2]

foolish me - it's too hot in here - i am out of office already - i check my queries tomorrow. but i see, this looks promising - t,

matthias

[Former Member]

I don't blame you.. with the temperature touching 3 digit figures!!! Hope you will find a place to cool off!!

[RichHeilman]

Just remember, if the string can be anywhere in the str being search you must wrapped the literal in %.

data: itrdir type table of trdir with header line.


select * into table itrdir from trdir
        <b> where name like '%RICH%'.</b>


loop at itrdir.
  write:/ itrdir-name.
endloop.

Regards,

Rich Heilman

PS.

Put yourself on the SDN world map (http://sdn.idizaai.be/sdn_world/sdn_world.html) and earn 25 points.

Spread the wor(l)d!

[matthias_kasig2]

i am on the sdn map - eddy de clerk told me, but i did not get 25 points

My problem persists - the 'LIKE' - hint wasn't bad, but does not work in <i>'for all entries in'</i> syntax.

What I am aiming at is:

  SELECT matnr kurztext langtext
    FROM zkatalog_add
  INTO TABLE ig_kat
  FOR ALL ENTRIES IN ig_data
      WHERE
  kurztext LIKE '%' ig_data-zl_artnr '%'.

btw, how do I combine % with variables if I want to say something like:

<i>where kurztext like %structure-field1%.</i>

regards, Matthias

[Former Member]

You may need to add a field in your ig_data table where you concatenate the '%' signs with the ig_data-zl_artnr value. Then use the new field in the LIKE statement.

[Former Member]

Hi mathias,Choosing a Table Type

The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.

Standard tables

This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.

Sorted tables

This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.

Hashed tables

This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.

reward if helpful.

regards,

keerthi.