table buffer..

[Former Member]

A table is buffered. By select statement i dont want to get the data from table buffer. i want to get the data from database. how?

[alex_m]

Use bypass buffer statement.

[Former Member]

Hello,

U can use the key word<b> bye-passing buffer</b> in select stmt.

Performance: 



Storing database tables in a local buffer (see SAP buffering) can lead to considerable time savings in a client/server environment, since the access time across the network is considerably higher than that required to access a locally-buffered table. 



Notes 
A SELECT statement on a table for which SAP buffering has been declared in the ABAP Dictionary usually reads data from the SAP buffer without accessing the database. This does not apply when you use: 
- SELECT SINGLE FOR UPDATE or 
- SELECT DISTINCT in the SELECT clause, 
- BYPASSING BUFFER in the FROM clause, 
- ORDER BY f1 ... fn in the ORDER BY clause, 
- Aggregate functions in the SELECT clause, 
- When you use IS [NOT] NULL in the WHERE condition, 
or when the table has generic buffering and the appropriate section of the key is not specified in the WHERE condition. 



The SELECT statement does not perform its own authorization checks. You should write your own at program level. 



Proper synchronization of simultaneous access by several users to the same set of data cannot be assured by the database lock mechanism. In many cases, you will need to use the SAP locking mechanism. 



Changes to data in the database are not made permanent until a database commit (see LUW) occurs. Up to this point, you can undo any changes using a databse rollback (see Programming Transactions). At the lowest isolation level (see lock mechanism ), the "Uncommitted Read", it can sometimes be the case that data selected by a SELECT statement was never written to the database. While a program is selecting data, a second program could be adding data to, changing data in, or deleting data from the database at the same time. If the second program then executes a rollback, the first program has selected a set of data that may only represent a temporary state from the database. If this kind of "phantom data" is unacceptable in the context of your application, you must either use the SAP locking mechanism or change the isolation level of the database system to at least "Committed Read" (see locking mechanism). 



In a SELECT - ENDSELECT loop, the CONTINUE statement terminates the current loop pass and starts the next. 



If a SELECT - ENDSELECT loop contains a statement that triggers a database commit, the cursor belonging to the loop is lost and a program termination and runtime error occur. Remote Function Calls and changes of screen always lead to a database commit. The following statements are consequently not allowed wihtin a SELECT-ENDSELECT loop: CALL FUNCTION ... STARTING NEW TASK , CALL FUNCTION ... DESTINATION , CALL FUNCTION ... IN BACKGROUND TASK , CALL SCREEN, CALL DIALOG, CALL TRANSACTION, and MESSAGE. 



On some database systems (for example DB2/390) 
locking conflicts can be caused even by read access. You can prevent this problem from occurring using regular database commits. 

If useful reward.

Vasanth

[Former Member]

select * from ztable bypassing buffer

into table itab

where field in s_field.

[Former Member]

Hi

SELECT * FROM <TABLE> BYPASSING BUFFER WHERE .... .

Max