<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: tables in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/tables/m-p/1582355#M262661</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Standard Internal Tables &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to &lt;/P&gt;&lt;P&gt;the number of table entries. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Sorted Internal Tables &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non-unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of &lt;/P&gt;&lt;P&gt;table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hashed Internal Tables &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and &lt;/P&gt;&lt;P&gt;using internal tables that are similar to database tables.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;the prerequisite for a binary search on an internal table is it should be sorted.&lt;/P&gt;&lt;P&gt;READ TABLE itab WITH KEY k1 = v1 ... kn = vn &lt;/P&gt;&lt;P&gt;[BINARY SEARCH] [additions].&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;2.native and open sql&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Open SQL allows you to access all database tables known to the SAP system, regardless of the database manufacturer. Sometimes, however, we may want to use database-specific SQL statements called Native SQL in your ABAP/4 program. &lt;/P&gt;&lt;P&gt;To avoid incompatibilities between different database tables and also to make ABAP/4 programs independent of the database system in use, SAP has created a set of separate SQL statements called Open SQL. Open SQL contains a subset of standard SQL statements as well as some enhancements which are specific to SAP. &lt;/P&gt;&lt;P&gt;A database interface translates SAP's Open SQL statements into SQL commands specific to the database in use. Native SQL statements access the database directly &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;3.memory&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SAP and ABAP Memory &lt;/P&gt;&lt;P&gt;There is a difference between the cross-transaction SAP memory and the transaction-specific ABAP memory. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Global SAP memory &lt;/P&gt;&lt;P&gt;The global SAP memory is available to a user during the entire duration of a terminal session. Its contents are retained across transaction boundaries as well as external and internal sessions. The SET PARAMETER and GET PARAMETER statements allow you to write to, or read from, the SAP memory. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Input fields on screens can be linked with parameters in the SAP memory, which allows you to preassign values to the input fields on initial screens. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With general screens, the linking takes place during the definition of the screen using the Screen Painter tool. When setting the field attributes of an input field, you can specify the ID of an SPA/GPA parameter in the Parameter-ID attribute. In the checkboxes SET Parameter and GET Parameter you can specify whether the screen field is filled with the value of the SPA/GPA parameter at the time of PBO or whether the SPA/GPA parameter is filled with the user input on the screen at the time of PAI. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With selection screens, the linking is carried out using the MEMORY ID addition to the PARAMETERS or SELECT-OPTIONS statement. If you specify an SPA/GPA parameter ID, when declaring a parameter or selection criterion, the relevant input field is linked with the parameter. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Local SAP memory &lt;/P&gt;&lt;P&gt;The local SAP memory is available to the user throughout a transaction, within which you can also call other program units, for example using SUBMIT or CALL TRANSACTION. With SET PARAMETER you write to both the global and the local SAP memory. If the global SAP memory is changed by an external mode of the same user, the local SAP memory remains unchanged. This ensures that parameters set in the frame of a transaction remain unchanged until the end of this transaction. The local SAP memory is deleted after the transaction is ended. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;ABAP memory &lt;/P&gt;&lt;P&gt;The contents of the ABAP memory are retained only during the lifetime of an external session (see also Organization of Modularization Units). You can retain or pass data across internal sessions. The EXPORT TO MEMORY and IMPORT FROM MEMORY statements allow you to write data to, or read data from, the ABAP memory. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Please consult Data Area and Modularization Unit Organization documentation as well. &lt;/P&gt;&lt;P&gt;and &lt;/P&gt;&lt;P&gt;Memory Structures of an ABAP Program &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;rgds&lt;/P&gt;&lt;P&gt;anver&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;if hlped mark points&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 29 Sep 2006 14:36:55 GMT</pubDate>
    <dc:creator>anversha_s</dc:creator>
    <dc:date>2006-09-29T14:36:55Z</dc:date>
    <item>
      <title>tables</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/tables/m-p/1582354#M262660</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi experts,&lt;/P&gt;&lt;P&gt;I have some doubts for interview.Please explain me.I read in some material but not clear.&lt;/P&gt;&lt;P&gt;1)What are tables(I know this)?How to distinguish between standard sorted and hashed?and usages. &lt;/P&gt;&lt;P&gt;2)open sql and native sql?&lt;/P&gt;&lt;P&gt;3)abap memory and sap memory?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 29 Sep 2006 14:33:21 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/tables/m-p/1582354#M262660</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2006-09-29T14:33:21Z</dc:date>
    </item>
    <item>
      <title>Re: tables</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/tables/m-p/1582355#M262661</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Standard Internal Tables &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to &lt;/P&gt;&lt;P&gt;the number of table entries. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Sorted Internal Tables &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non-unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of &lt;/P&gt;&lt;P&gt;table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hashed Internal Tables &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and &lt;/P&gt;&lt;P&gt;using internal tables that are similar to database tables.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;the prerequisite for a binary search on an internal table is it should be sorted.&lt;/P&gt;&lt;P&gt;READ TABLE itab WITH KEY k1 = v1 ... kn = vn &lt;/P&gt;&lt;P&gt;[BINARY SEARCH] [additions].&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;2.native and open sql&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Open SQL allows you to access all database tables known to the SAP system, regardless of the database manufacturer. Sometimes, however, we may want to use database-specific SQL statements called Native SQL in your ABAP/4 program. &lt;/P&gt;&lt;P&gt;To avoid incompatibilities between different database tables and also to make ABAP/4 programs independent of the database system in use, SAP has created a set of separate SQL statements called Open SQL. Open SQL contains a subset of standard SQL statements as well as some enhancements which are specific to SAP. &lt;/P&gt;&lt;P&gt;A database interface translates SAP's Open SQL statements into SQL commands specific to the database in use. Native SQL statements access the database directly &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;3.memory&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;SAP and ABAP Memory &lt;/P&gt;&lt;P&gt;There is a difference between the cross-transaction SAP memory and the transaction-specific ABAP memory. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Global SAP memory &lt;/P&gt;&lt;P&gt;The global SAP memory is available to a user during the entire duration of a terminal session. Its contents are retained across transaction boundaries as well as external and internal sessions. The SET PARAMETER and GET PARAMETER statements allow you to write to, or read from, the SAP memory. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Input fields on screens can be linked with parameters in the SAP memory, which allows you to preassign values to the input fields on initial screens. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With general screens, the linking takes place during the definition of the screen using the Screen Painter tool. When setting the field attributes of an input field, you can specify the ID of an SPA/GPA parameter in the Parameter-ID attribute. In the checkboxes SET Parameter and GET Parameter you can specify whether the screen field is filled with the value of the SPA/GPA parameter at the time of PBO or whether the SPA/GPA parameter is filled with the user input on the screen at the time of PAI. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With selection screens, the linking is carried out using the MEMORY ID addition to the PARAMETERS or SELECT-OPTIONS statement. If you specify an SPA/GPA parameter ID, when declaring a parameter or selection criterion, the relevant input field is linked with the parameter. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Local SAP memory &lt;/P&gt;&lt;P&gt;The local SAP memory is available to the user throughout a transaction, within which you can also call other program units, for example using SUBMIT or CALL TRANSACTION. With SET PARAMETER you write to both the global and the local SAP memory. If the global SAP memory is changed by an external mode of the same user, the local SAP memory remains unchanged. This ensures that parameters set in the frame of a transaction remain unchanged until the end of this transaction. The local SAP memory is deleted after the transaction is ended. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;ABAP memory &lt;/P&gt;&lt;P&gt;The contents of the ABAP memory are retained only during the lifetime of an external session (see also Organization of Modularization Units). You can retain or pass data across internal sessions. The EXPORT TO MEMORY and IMPORT FROM MEMORY statements allow you to write data to, or read data from, the ABAP memory. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Please consult Data Area and Modularization Unit Organization documentation as well. &lt;/P&gt;&lt;P&gt;and &lt;/P&gt;&lt;P&gt;Memory Structures of an ABAP Program &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;rgds&lt;/P&gt;&lt;P&gt;anver&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;if hlped mark points&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 29 Sep 2006 14:36:55 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/tables/m-p/1582355#M262661</guid>
      <dc:creator>anversha_s</dc:creator>
      <dc:date>2006-09-29T14:36:55Z</dc:date>
    </item>
    <item>
      <title>Re: tables</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/tables/m-p/1582356#M262662</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi Nithin,&lt;/P&gt;&lt;P&gt; Here are the answers to your question..&lt;/P&gt;&lt;P&gt;1. &lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="843065"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;2. &lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="1370408"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;3. &amp;lt;b&amp;gt;Difference&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="2055214"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&amp;lt;b&amp;gt;Examples &amp;lt;/b&amp;gt;..&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="2441465"&gt;&lt;/A&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 29 Sep 2006 14:38:58 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/tables/m-p/1582356#M262662</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2006-09-29T14:38:58Z</dc:date>
    </item>
  </channel>
</rss>

