Concatenation in select statement ?

I need some help from you people. I need to write a select statement, and in the WHERE condition I need to compare the table field with concatenation of two fields ( say F1 and F2) which I already determined.
And I need to do this for say 1 million set of field combinations of F1 and F2. I can write a loop before the select statement and find all the concatenations of F1 and F2 . But I want to make it less time consuming.
Please let me know how to do this.
Thanks

Why not use a range. Add all of the combinations to the range and then use the range in your Select statement.
Something like this.
report zrich_0003.
TYPes: begin of trange,
       value(30) type c,
       end of trange.
data: xrange type trange.
ranges: r_range for xrange.
r_range-sign   = 'I'.
r_range-option = 'EQ'.
concatanate 'A' 'B' into r_range-low.
append r_range.
r_range-sign   = 'I'.
r_range-option = 'EQ'.
concatanate 'C' 'D' into r_range-low.
append r_range.
r_range-sign   = 'I'.
r_range-option = 'EQ'.
concatanate 'E' 'F' into r_range-low.
append r_range.
Select * into itable from ztable
         where some_field in r_range.
Regards,
Rich Heilman

Similar Messages

How to utilize index in selection statement

hi
how to utilize index in selection statement and how is it reduces performance whether another alternative is there to reduce performance .
thanks

Hi Suresh,
For each SQL statement, the database optimizer determines the strategy for accessing data records. Access can be with database indexes (index access), or without database indexes (full table scan).The cost-based database optimizer determines the access strategy on the basis of:
*Conditions in the WHERE clause of the SQL statement
*Database indexes of the table(s) affected
*Selectivity of the table fields contained in the database indexes
*Size of the table(s) affected
*The table and index statistics supply information about the selectivity of table fields, the selectivity of combinations of table fields, and table size. Before a database access is performed, the database optimizer cannot calculate the exact cost of a database access. It uses the information described above to estimate the cost of the database access.The optimization calculation is the amount by which the data blocks to be read (logical read accesses) can be reduced. Data blocks show the level of detail in which data is written to the hard disk or read from the hard disk.
Inroduction to Database Indexes
When you create a database table in the ABAP Dictionary, you must specify the combination of fields that enable an entry within the table to be clearly identified. Position these fields at the top of the table field list, and define them as key fields.
After activating the table, an index is created (for Oracle, Informix, DB2) that consists of all key fields. This index is called a primary index. The primary index is unique by definition. As well as the primary index, you can define one or more secondary indexes for a table in the ABAP Dictionary, and create them on the database. Secondary indexes can be unique or non-unique. Index records and table records are organized in data blocks.
If you dispatch an SQL statement from an ABAP program to the database, the program searches for the data records requested either in the database table itself (full table scan) or by using an index (index unique scan or index range scan). If all fields requested are found in the index using an index scan, the table records do not need to be accessed.
A data block shows the level of detail in which data is written to the hard disk or read from the hard disk. Data blocks may contain multiple data records, but a single data record may be spread across several data blocks.
Data blocks can be index blocks or table blocks. The database organizes the index blocks in the form of a multi-level B* tree. There is a single index block at root level, which contains pointers to the index blocks at branch level. The branch blocks contain either some of the index fields and pointers to index blocks at leaf level, or all index fields and a pointer to the table records organized in table blocks. The index blocks at leaf level contain all index fields and pointers to the table records from the table blocks.
The pointer that identifies one or more table records has a specific name. It is called, for example, ROWID for Oracle databases. The ROWID consists of the number of the database file, the number of the table block, and the row number within the table block.
The index records are stored in the index tree and sorted according to index field. This enables accelerated access using the index. The table records in the table blocks are not sorted.
An index should not consist of too many fields. Having a few very selective fields increases the chance of reusability, and reduces the chance of the database optimizer selecting an unsuitable access path.
Index Unique Scan
If, for all fields in a unique index (primary index or unique secondary index), WHERE conditions are specified with '=' in the WHERE clause, the database optimizer selects the access strategy index unique scan.
For the index unique scan access strategy, the database usually needs to read a maximum of four data blocks (three index blocks and one table block) to access the table record.
select * from VVBAK here vbeln = '00123' ......end select.
In the SELECT statement shown above, the table VVBAK is accessed. The fields MANDT and VBELN form the primary key, and are specified with '=' in the WHERE clause. The database optimizer therefore selects the index unique scan access strategy, and only needs to read four data blocks to find the table record requested.
Index Range Scan
select * from VVBAP here vbeln = '00123' ......end select.
In the example above, not all fields in the primary index of the table VVBAP (key fields MANDT, VBELN, POSNR) are specified with '=' in the WHERE clause. The database optimizer checks a range of index records and deduces the table records from these index records. This access strategy is called an index range scan.
To execute the SQL statement, the DBMS first reads a root block (1) and a branch block (2). The branch block contains pointers to two leaf blocks (3 and 4). In order to find the index records that fulfill the criteria in the WHERE clause of the SQL statement, the DBMS searches through these leaf blocks sequentially. The index records found point to the table records within the table blocks (5 and 6).
If index records from different index blocks point to the same table block, this table block must be read more than once. In the example above, an index record from index block 3 and an index record from index block 4 point to table records in table block 5. This table block must therefore be read twice. In total, seven data blocks (four index blocks and three table blocks) are read.
The index search string is determined by the concatenation of the WHERE conditions for the fields contained in the index. To ensure that as few index blocks as possible are checked, the index search string should be specified starting from the left, without placeholders ('_' or %). Because the index is stored and sorted according to the index fields, a connected range of index records can be checked, and fewer index blocks need to be read.
All index blocks and table blocks read during an index range scan are stored in the data buffer at the top of a LRU (least recently used) list. This can lead to many other data blocks being forced out of the data buffer. Consequently, more physical read accesses become necessary when other SQL statements are executed
DB Indexex :Concatenation
In the concatenation access strategy, one index is reused. Therefore, various index search strings also exist. An index unique scan or an index range scan can be performed for the various index search strings. Duplicate entries in the results set are filtered out when the search results are concatenated.
Select * from vvbap where vbeln in ('00123', '00133', '00134').
endselect.
In the SQL statement above, a WHERE condition with an IN operation is specified over field VBELN. The fields MANDT and VBELN are shown on the left of the primary index. Various index search strings are created, and an index range scan is performed over the primary index for each index search string. Finally, the result is concatenated.
Full Table Scan
select * from vvbap where matnr = '00015'.
endselect
If the database optimizer selects the full table scan access strategy, the table is read sequentially. Index blocks do not need to be read.
For a full table scan, the read table blocks are added to the end of an LRU list. Therefore, no data blocks are forced out of the data buffer. As a result, in order to process a full table scan, comparatively little memory space is required within the data buffer.
The full table scan access strategy is very effective if a large part of a table (for example, 5% of all table records) needs to be read. In the example above, a full table scan is more efficient than access using the primary index.
In Brief
Index unique scan: The index selected is unique (primary index or unique secondary index) and fully specified. One or no table record is returned. This type of access is very effective, because a maximum of four data blocks needs to be read.
Index range scan: The index selected is unique or non-unique. For a non-unique index, this means that not all index fields are specified in the WHERE clause. A range of the index is read and checked. An index range scan may not be as effective as a full table scan. The table records returned can range from none to all.
Full table scan: The whole table is read sequentially. Each table block is read once. Since no index is used, no index blocks are read. The table records returned can range from none to all.
Concatenation: An index is used more than once. Various areas of the index are read and checked. To ensure that the application receives each table record only once, the search results are concatenated to eliminate duplicate entries. The table records returned can range from none to all.
Regards,
Balaji Reddy G
***Rewards if answers are helpful

Re: Select statement fails under Express, but works underForte when usi

Hi there,
I have logged this with Forte and it as been recognized as a bug ( #46554 ).
The Express methods you need to look at if you want to modify this behavior
are :
1 - BusinessQuery.BuildQuery() starting at line 217
2 - SqlQuery.GetWhereText() starting at line 60
We have gotten around the problem by modifying what Express generates by
changing it from ( col1, col2 ) in ( select col1, col2 ... ) to ( col1 +
col2 ) in ( select col1 + col2 ... )
Just one thing i'm not sure that the '+' is standard on every DBMS for
concatenation.
We are using SQL Server 6.5
Hope this helps.
Christian Boult ([email protected])
Programmeur - Analyste
Influatec inc.
-----Original Message-----
From: Metcalf, Roger <[email protected]>
To: '[email protected]' <[email protected]>
Date: Thursday, May 06, 1999 1:55 PM
Subject: Select statement fails under Express, but works under Forte when
using DB2
Express sometimes (e.g. with nested windows) generates SQL with a select
subquery, e.g.
select x1, x2 from t1 where (x1,x2) in (select x1,x2 from t2.....)
This fails on DB2 with a message that the comma in the where clause (x1,x2)
is not allowed.
This works on Oracle.
Does anyone have a workaround or other suggestion?
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

joe.meszaros wrote:
(SELECT ? AS Id, ? AS UserBytes FROM dual)I suggest that you test to see if that statement and ONLY that statement works at all.
There are rules for bind variables and that statement certainly looks suspicious.
If you can't get that to work then the rest of the attempt is pointless.

Long running select statement and v$session_longops

Oracle Version: 10.2.0.4
I've a long running sql query that takes the estimated 6 minutes to complete and return the result.
While it's running I'd like to observe it into the view v$session_longops.
I altered the session that runs the query with
ALTER SESSION SET timed_statistics=TRUE;The tables it queries have gathered statistics on them.
However I don't see any rows in the view v$session_longops for the respective SID and serial#. Why is that? What am I missing?
Thank you!

Hi,
Now I understand what you all meant by "loops" here .. Yes, the query does nested loops as one can see from the execution plan. So it could be the reason
SELECT STATEMENT, GOAL = ALL_ROWS
SORT GROUP BY
CONCATENATION
   TABLE ACCESS BY LOCAL INDEX ROWID     TABLE_1
    NESTED LOOPS
     NESTED LOOPS
      TABLE ACCESS BY GLOBAL INDEX ROWID     TABLE_2
       INDEX RANGE SCAN                           IPK_t2_CDATE
      TABLE ACCESS BY INDEX ROWID     TABLE_3
       INDEX RANGE SCAN                     IPK_T3
     PARTITION RANGE ALL
      INDEX RANGE SCAN     IRGP_REGCODE
   TABLE ACCESS BY LOCAL INDEX ROWID     TABLE_1
    NESTED LOOPS
     NESTED LOOPS
      TABLE ACCESS BY GLOBAL INDEX ROWID     TABLE_2
       INDEX RANGE SCAN                       IPK_t2_STATUS
      TABLE ACCESS BY INDEX ROWID     TABLE_3
       INDEX RANGE SCAN                       IPK_T3
     PARTITION RANGE SINGLE
      INDEX RANGE SCAN                     IRGP_REGCODE

Select statement doesn't deliver the result !

Hello,
Can please someone help, why this SELECT statement doesn't deliver any result.
    SELECT TDNAME TDID TDSPRAS TDOBJECT FROM STXH
    INTO CORRESPONDING FIELDS OF TABLE I_TEXT
    WHERE TDOBJECT = 'MVKE'
    AND TDNAME = p_matnr
    AND TDID = '0001'.

MVKE is the text which is sales org specific , right ?
So i dont think you will have any text with the material name.
it should be material concatenated with Sales org and distribution channel atleast.
go to se11 and see the table contents for STXH where object = MVKE...
try concatenate p_matnr p_vkorg p_vtweg into P_matnr.
and do selection for this.
Edited by: Sujamol Augustine on May 13, 2008 10:02 PM

If statement in select statement alias

I have the following select statement. It has the alias Survivors, Deaths and "All Cases". Is it posible to use :P_LANGUAGE variable to say that -- IF :P_LANGUAGE = FRENCH THEN alias are Survivants for survivors, Décès for Deaths, Tous_les_cas for All Cases. Please advise
SELECT ALL T_NTR_MULTIBAR.CAT, T_NTR_MULTIBAR.NUM_CASES_LEFTBAR AS Survivors,
T_NTR_MULTIBAR.NUM_CASES_MIDDLEBAR AS Deaths, T_NTR_MULTIBAR.NUM_CASES_RIGHTBAR AS "All Cases"
FROM T_NTR_MULTIBAR
WHERE INSTANCE_NUM = :P_INSTANCENUM
order by ORDERS

You may not be able to add this condition inside the SQL Statement. But you can add this condition outside the statement, if you're using PL/SQL...
IF :p_language = french THEN
SELECT ALL t_ntr_multibar.cat,
t_ntr_multibar.num_cases_leftbar AS survivors,
t_ntr_multibar.num_cases_middlebar AS deaths,
t_ntr_multibar.num_cases_rightbar AS "All Cases"
ELSE
END IF;

How to get all values from an interval using select statement

Hi,
Is it possible to write a select statement that returns all values from an interval? Interval boundaries are variable.
something like this:
select (for x in 1,1024 loop x end loop) from dual
(this, of course, doesn't work)
The result in this example should be 1024 rows of numbers from 1 to 1024. These numbers are parameters, so it is not possible to create a table with predefined values.
Thanks in advance for your help,
Mia.

For your simple case, with a lower boundary of 1, you can use:
SELECT rownum
FROM all_objects
WHERE rownum <= 1024For a set of number between say 50 - 100, you can use something like:
SELECT rownum + (50 - 1)
FROM all_objects
WHERE rownum <= (100 - 50 + 1)Note, that all_objects was used only because it generally has a lot of rows. Any table with at least the number of rows in your range will work.
TTFN
John

Select statement operators in ecc 6.

Hi Experts,
I have a small doubt about the '>=' ( greater than or equal to ) operator usage in select statement. Is this operator by any chance perform not as desired in ECC 6.0. Is it a good option to use 'GE' instead of '>='. ?
It may sound a bit awkward, but still I would like to know. I am facing a situation, which could be related to this. An early response would be highly appreciated.
I would request,you NOT TO REPLY with links/explanations which says how to use select statement. Only answer if you have the answers related to this query.
Regards,
Sandipan

>
Jaideep Sharma wrote:
> Hi,
> The only difference is GE will take a little more time than >= as system need to convert the keyword into actual operator when fetching data from Database.
>
> KR Jaideep,
????? Every Open SQL statements is translated to the SQL slang the underlying database is talking regardless if you type GE or >=
If the result differs using >= or GE i would open a call at SAP instead of asking in SDN.

How to find the number of fetched lines from select statement

Hi Experts,
Can you tell me how to find the number of fetched lines from select statements..
and one more thing is can you tell me how to check the written select statement or written statement is correct or not????
Thanks in advance
santosh

Hi,
Look for the system field SY_TABIX. That will contain the number of records which have been put into an internal table through a select statement.
For ex:
data: itab type mara occurs 0 with header line.
Select * from mara into table itab.
Write: Sy-tabix.
This will give you the number of entries that has been selected.
I am not sure what you mean by the second question. If you can let me know what you need then we might have a solution.
Hope this helps,
Sudhi
Message was edited by:
Sudhindra Chandrashekar

Use of LIKE in where clause of select statement for multiple records

Hi Experts,
I have a account number field which is uploaded from a file. Now this account numbers uploaded does not match fully with sap table account numbers but it contains all of the numbers provided in the file mostly in the upright positions.
For example in file we have account number as 2ARS1 while in sap table the value is 002ARS1.
And i want to fetch data from sap table based on account number uploaded. So, i am trying to use LIKE with for all entries but its not working as mentioned below but LIKE is not working with FOR ALL ENTRIES.
data : begin of t_dda occurs 0,
        dda(19) type c,
       end of t_dda.
data : begin of t_bukrs occurs 0,
        bukrs type t012k-bukrs,
       end of t_bukrs.
data : dda type t012k-bankn,
       w_dda type t012k-bankn.
CONCATENATE '%'
                         '2ARS1'
                 INTO W_DDA.
MOVE W_DDA TO T_DDA-DDA.
APPEND T_DDA.
CLEAR T_DDA.
free t_bukrs.
SELECT BUKRS
FROM T012K
into TABLE t_bukrs
    for all entries in t_dda
WHERE BANKN like t_dda-dda.
Can anybody suggest what should i use to get the data for multiple account numbers using one select statement only instead on using SELECT UP TO 1 ROWS in LOOP....ENDLOOP ?
Thanks in advance,
Akash

Hi,
yes, For All entries won't work for LIKE with '% '.
I think the other alternative is go for Native SQL by writing sub-query
sample code is here:
data: begin of i_mara occurs 0,
          matnr like mara-matnr,
          matkl like mara-matkl,
       end of i_mara.
exec sql.
select matnr, matkl from mara where matnr in (select matnr from marc) and matnr like '%ma' into :i_mara
endexec.
loop at i_mara.
write:/ i_mara-matnr, i_mara-matkl.
endloop.
hope u got it.
regards
Mahesh
Edited by: Mahesh Reddy on Jan 21, 2009 2:32 PM

What is the use of additon in up to 1 rows in SELECT statement

Hi All,
         What is the use of up to 1 rows in select statement.
for example
SELECT kostl
      FROM pa0001
      INTO y_lv_kostl UP TO 1 ROWS
      WHERE pernr EQ pernr
      AND endda GE sy-datum.
    ENDSELECT.
I'm unable to get in wat situations we hav to add up to 1 rows
please help me out...
Thanks,
santosh.

Hi,
Use "select up to 1 rows" only if you are sure that all the records returned will have the same value for the field(s) you are interested in. If not, you will be reading only the first record which matches the criteria, but may be the second or the third record has the value you are looking for.
The System test result showed that the variant Single * takes less time than Up to 1 rows as there is an additional level for COUNT STOP KEY for SELECT ENDSELECT UP TO 1 ROWS.
The 'SELECT .... UP TO 1 ROWS' statement is subtly different. The database selects all of the relevant records that are defined by the WHERE clause, applies any aggregate, ordering or grouping functions to them and then returns the first record of the result set.
Regards,
Bhaskar

Secondary Index Select Statement Problem

Hi friends.
I have a issue with a select statement using secondary index,
SELECT SINGLE * FROM VEKP WHERE VEGR4 EQ STAGE_DOCK
                                  AND VEGR5 NE SPACE
                                  AND WERKS EQ PLANT
        %_HINTS ORACLE
        'INDEX("&TABLE&" "VEKP~Z3" "VEKP^Z3" "VEKP_____Z3")'.
given above statement is taking long time for processing.
when i check for the same secondary index in vekp table i couldn't see any DB index name with vekp~z3 or vekp^z3 or vekp____z3.
And the sy-subrc value after select statement is 4. (even though values avaliable in VEKP with given where condition values)
My question is why my select statement is taking long time and sy-subrc is 4?
what happens if a secnodary index given in select statement, which is not avaliable in that DB Table?

Hi,
> ONe more question: is it possible to give more than one index name in select statement.
yes you can:
read the documentation:
http://download.oracle.com/docs/cd/A97630_01/server.920/a96533/hintsref.htm#5156
index_hint:
This hint can optionally specify one or more indexes:
- If this hint specifies a single available index, then the optimizer performs
a scan on this index. The optimizer does not consider a full table scan or
a scan on another index on the table.
- If this hint specifies a list of available indexes, then the optimizer
considers the cost of a scan on each index in the list and then performs
the index scan with the lowest cost. The optimizer can also choose to
scan multiple indexes from this list and merge the results, if such an
access path has the lowest cost. The optimizer does not consider a full
table scan or a scan on an index not listed in the hint.
- If this hint specifies no indexes, then the optimizer considers the
cost of a scan on each available index on the table and then performs
the index scan with the lowest cost. The optimizer can also choose to
scan multiple indexes and merge the results, if such an access path
has the lowest cost. The optimizer does not consider a full table scan.
Kind regards,
Hermann

BI Publisher : SELECT statement in RTF template

Hi Guys
I have written a BI Publisher Report using XML file created from Oracle Reports(in Oracle Apps).
Repors runs from Oracle Apps perfectly ok. Now I need to fetch some data from couple of tables and display on the Report.
I am wondering whether I can directly code SELECT statement in RTF file rather than messing with Oracle Report(.rdf) file.
Please advise.
Thanks and Regards
Vijay

Hey Vijay,
You cannot query in RTF using select :)..
You have to mess/play with RDF to do it ;)
Oh wait, did i say , we cannot in RTF, we can , but that is difficult approach to go with., keep this as an end of the world option.

Can we use is null in our select statement in ABAP program

hi,
I want to use 'is nul' or 'not null' in select statement of my ABAP program for any field. I have written below query but I am getting sy-subrc = 4 and getting no data. Can anyone resolve this.

Hi,
I think you've posted your question on the wrong forum. This is the SAP Business One development forum which is not part of ERP and doesn't include any ABAP or Netweaver programming.
For a list of forums please see here:
http://forums.sdn.sap.com/index.jspa
Kind Regards,
Owen

Performance issue - Select statement

Hi I am having the 10 lack records in the KONP table . If i am trying to see all the records in SE11 , it is giving the short dump TSV_TNEW_PAGE_ALLOC_FAILED . I know this is because of less memory in the Server . Is there any other way to get the data ? How to optimise the below SELECT statement if i have large data in the table .
i_condn_data - is having 8 lack records .
SELECT knumh kznep valtg valdt zterm
        FROM konp
        INTO TABLE i_condn_data_b
        FOR ALL ENTRIES IN i_condn_data
        WHERE knumh = i_condn_data-knumh
        AND kschl = p_kschl.
Please suggest .

Hi,
try to use "UP TO n ROWS" to control the quantity of selected data in each Loop step.
Something like this:
sort itab by itab-knumh.
flag = 'X'.
while flag = 'X'.
SELECT knumh kznep valtg valdt zterm
FROM konp
INTO TABLE i_condn_data_b UP TO one_million ROWS
WHERE knumh > new_value_for_selection
AND kschl = p_kschl.
describe table i_condn_data_b lines i.
read table i_condn_data_b index i.
new_value_for_selection = i_condn_data_b-knumh.
*....your logic for table i_condn_data_b
if one_million > i.
clear flag.
endif.
endwhile.
Regards

Concatenation in select statement ?

Similar Messages

Maybe you are looking for