About Read table

Can any body explain about Read table and when it can use.

Hi,
When u want to read a record based on some condition then u can use READ.
LOOP AT itab.
READ TABLE itab WITH KEY matnr = itab-matnr.
IF sy-subrc = 0.
ENDIF.
ENDLOOP.
U can read only a single record.
U can also use
READ TABLE itab INDEX 1.
Reward points if this is helpful.

Similar Messages

  • Hii guyzz i want to know about read table

    guyzz,
               i have to delete a value from the table eg: despatch date but after i delete the the date i want the date in the remaining field (the fields i doesnt delete the date ) to add into hte space in deleted(now it contins 00000) and it all should be done in read table area
    i wont need the program only logic will do guyzz
    thanks in advance... and points will given to those who help me with this...

    Apple - Apple Watch

  • Question about reading generic tables with keys

    Hello
    I'm wondering if it's possible to read a generic table with key statement:
    FIELD-SYMBOLS:
        <lv_key>         TYPE zconf_key,
        <lt_data_bi>     TYPE INDEX TABLE,
        <lt_data_ai>     TYPE INDEX TABLE,
        <ls_data_bi>     TYPE any,
        <ls_data_ai>     TYPE any.
    * create data types
      CREATE DATA lt_data_bi TYPE (ls_node-data_table_type).
      ASSIGN lt_data_bi->* TO <lt_data_bi>.
      CREATE DATA lt_data_ai TYPE (ls_node-data_table_type).
      ASSIGN lt_data_ai->* TO <lt_data_ai>.
    * do check
      LOOP AT <lt_data_ai> ASSIGNING <ls_data_ai>.
        ASSIGN COMPONENT 'KEY' OF STRUCTURE <ls_data_ai> TO <lv_key>.
        READ TABLE <lt_data_bi> WITH KEY key = <lv_key>
        ASSIGNING <ls_data_bi> BINARY SEARCH.
    I receive the message: "The specified type has no structure and therefore no component called KEY" in the read statement above.
    Does anyone has an idea what I can do here?
    Regards,
      Mathias

    Mathias Glockner wrote:
    >     READ TABLE <lt_data_bi> WITH KEY key = <lv_key>
    In your structure ls_data_bi there is no field called KEY . please check whether you have field KEY in structure
    a®s

  • "Read table" and field symbols

    Hello all,
    I have a (hopefully simple) question. Let's suppose I want to do the following:
    loop at itab1 assigning <fs1>.
      read table itab2 assigning <fs2> with table key <fs1>-field1.
      if sy-subrc eq 0.
        move <fs2>-field1 to ls_out-field1.
      endif.
      read table itab3 assigning <fs3> with table key <fs1>-field2.
      if sy-subrc eq 0.
        move <fs3>-field1 to ls_out-field2.
      endif.
    endloop.
    It's also possible to do the following instead:
    loop at itab1 assigning <fs1>.
      unassign: <fs2>,
                <fs3>.
      read table itab2 assigning <fs2> with table key <fs1>-field1.
      read table itab3 assigning <fs3> with table key <fs1>-field2.
      if <fs2> is assigned.
        move <fs2>-field1 to ls_out-field1.
      endif.
      if <fs3> is assigned.
        move <fs3>-field1 to ls_out-field2.
      endif.
    endloop.
    My question is: is it "better" to check sy-subrc after each read, and then do a move statement within that if statement, or is it better to check whether the field symbol is assigned each time I want to fill in a field and read everything at the same time?
    I'm only really concerned about the case where you don't want to drop out of the loop after the read (so if the read fails you just don't fill any data in). I'm also discounting potential human error (otherwise the sy-subrc method wins hands-down).

    Just to close this one (albeit somewhat belatedly). I asked Harry Dietz (the ABAP Performance blogging fella) what he would suggest, and he says sy-subrc all the way. Checking that an integer is zero is considerably faster than checking for the assignment, or otherwise, of a field symbol. Furthermore, whilst the field symbol method has the potential to be faster than the sy-subrc method given some compiler optimizations, unfortunately these optimizations don't exist in the ABAP compiler - they're there in the Java compiler though! Shame really. Apparently the ABAP compiler is a pretty simple beast.
    Anyway - thanks Harry for clearing this one up!

  • Reading Tables in MS WORD using LabView & ActiveX

    I would like to be able to read tables contained in an MS WORD document using LabView and ActiveX. (I've been successful in doing this with Excel files.  ( I am not using the report generation toolkit.)  After searching numerous posts with similar questions about LV & ActiveX  I've not found any solution to my specific app.  In LabView I'm successful doing an "Automation Open", followed by a Property Node, to an Invoke Node ("Documents" Open) and then a Property Node with "TABLES" selected. That's where I get stuck. Now that I have a reference (?) to "Tables" I can't seem to figure out what I need to connect and follow that with in order to now read the Tables in my document.  I guess that's due to my lack of understanding as to what exactly this "Table" property node output actually is.  Can someone tell me what this reference output is referring to and how I can get to the Tables within the document from it?  I've tried connecting both a property node and invoke node to no avail.  Can someone point me in the right direction?
    Thanks. Ed

    Dear Ed,
    Figuring out "what I need to connect and follow that with" relates to the organization of the MS Word Object Model.  Please refer to the Word Object Model Reference MSDN >> MSDN Library >> Office Development >> 2007 Microsoft Office System >> Word 2007 >> Word 2007 Developer Reference >> Word Object Model Reference.  You can think of the Object Model as a software hierarchy.  You must start at the top of the hierarchy and work your way down to the item of interest.  You must descend the hierarchy one level at a time; you cannot skip levels.
    At each level of the hierarchy, you have access to the methods and properties of that "level".
    Click on the Tables Collection link from the Word Object Model Reference page.  Notice how Tables is at the top of the hierarchy.  When you have a LabVIEW reference to a Tables object (technically speaking a collection), you then have access to the methods and properties supported by this "level".  Click on the Tables Object Members link.  Here you will see that the Tables collection supports two methods, Add and Item, and also supports five properties, Application, Count, Creator, NestingLevel, and Parent.
    Notice how Mike gets the Count property of the Tables object.  He then uses the Item method to return a reference to an individual table.  The key thing to take away from this is how Mike uses the Item output node to gain access to the methods and properties of the Table object (not the Tables collection).  Mike has descended the hierarchy from Tables to Table.  He descends the hierarchy again with the Cell method and Range property of the Table and Cell object respectively.  Lastly, the Text property of the Range object, "Returns or sets the text in the specified range or selection."
    Effective LabVIEW programming with this type of ActiveX control requires a fair understanding of how Microsoft organized its software libraries.  The Object Model Reference is a good place to start visualizing how these libraries are organized.  Thank you for using the forums Ed, and thanks for your post, Mike.

  • Read table and binary search

    Hi all,
    I have a simple query regarding read int_tab with binary search.
    Why reading  internal table with binary search fails if it is sorted in descending order table must be sorted in ascending order?
    I check fo the algorithm of binary search, it does not talk about sort order. As far as my understanding goes binary search only require sorted table but while reading table in SAP it has to be sorted in ascending order!!

    By default binary search assumes that the sort order is ASCENDING.
    If you sort the list in descending and then try to binary search your quires will fail. Look at an example:
    Let the descending order internal table as:
    Field1      Field2
    Sam        50000
    John       34786
    Boob      54321
    Alice       12345
    When you do binary search with key = 'Sam' then it will directly go to 2nd and 3rd records for comparision. The binary search algorithm compares 'Sam' with 'John' and it concludes that 'Sam' is greater than 'John' and it will continue to look downward into the internal table. And when it reaches the end of the internal table then the value of SY-TABIX = 5 and SY-SUBRC = 8 (Key is greater than the all).
    And if you do binary search with key = 'Alice' then the binary search algorithm compares 'Alice' with 'John' and it concludes that 'Alice' is lower than 'John' and it will continue to look upward into the internal table. And when it reaches above the first record in internal table then the value of SY-TABIX = 1 and SY-SUBRC = 4 (points to the next largest entry).
    The only correct result you will get is when you execute statement with key='John' (In this particular case) . SY-TABIX = 2 and SY-SUBRC = 0. I think you got this binary search algorithm.

  • Read table  binary search

    Hi all,
    Can i use raed table binary search for Hased tables? I coded like this
    DATA:T_MODEL_HASH LIKE HASHED TABLE OF T_MODEL
    WITH UNIQUE KEY PBPINO  WITH HEADER LINE.
    READ TABLE t_model_hash WITH KEY pbpino = t_zwpbph-pbpapino
        BINARY SEARCH.
    But iam getting syntax error "cannot use explicit or implicit index operations on hased tables ".can any one let me know about this issue?

    Hi Priya,
    Hashed tables are managed by a hash algorithm. There is no logical index. The entries are not ordered in the memory. The position of a row is calculated by specifying a key using a hash function.
    A hashed table's performance in reads is NOT dependent on the number of records. However, it is intended for reads that will return only and only one record. It uses a "side-table" with a hash algorithm to store off the physical location of the record in the actual internal table. It is not NECESSARILY sorted/organized in an meaningful order (like a sorted table is). Please note that changes to a hashed tables records must be managed carefully.
    Please check this link to understand how to use hash table.
    http://help.sap.com/saphelp_erp2004/helpdata/en/fc/eb362c358411d1829f0000e829fbfe/frameset.htm
    Regards,
    Ferry Lianto

  • Need information about Internal Tables

    Hi Every one!
    I Need some information about Internal tables. Pls help be above the same.
    Thanks & with Regards,
    Chandra.

    Hi..,
    <b>
    Internal tables </b>
    Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.
    Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.
    <b>Internal Tables as Data Types</b>
    Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.
    <b>Line type</b>
    The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.
    <b>Key</b>
    The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.
    If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.
    The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.
    <b>
    Table type</b>
    The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
    <u>Standard tables</u> have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
    <u>
    Sorted tables</u> are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional 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. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
    <u>
    Hashed tables</u> have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
    <b>
    Generic Internal Tables</b>
    Unlike other local data types in programs, you do not have to specify the data type of an internal table fully. Instead, you can specify a generic construction, that is, the key or key and line type of an internal table data type may remain unspecified. You can use generic internal tables to specify the types of field symbols and the interface parameters of procedures . You cannot use them to declare data objects.
    <b>Internal Tables as Dynamic Data Objects</b>
    Data objects that are defined either with the data type of an internal table, or directly as an internal table, are always fully defined in respect of their line type, key and access method. However, the number of lines is not fixed. Thus internal tables are dynamic data objects, since they can contain any number of lines of a particular type. The only restriction on the number of lines an internal table may contain are the limits of your system installation. The maximum memory that can be occupied by an internal table (including its internal administration) is 2 gigabytes. A more realistic figure is up to 500 megabytes. An additional restriction for hashed tables is that they may not contain more than 2 million entries. The line types of internal tables can be any ABAP data types - elementary, structured, or internal tables. The individual lines of an internal table are called table lines or table entries. Each component of a structured line is called a column in the internal table.
    <b>
    Choosing a Table Type</b>
    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.
    <b>
    Standard tables</b>
    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.
    <b>Sorted tables</b>
    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.
    <b>
    Hashed tables</b>
    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.
    regards,
    sai ramesh

  • About important tables in FI

    Hi Friends,
    I would like to know something about the tables and the data flow. I've not been a part of customising a "Z" report as yet, and I'm sure I would have to do it any time.
    Please suggest to me as to where do I need to start off and the importance of learning the table names pertaining to FI/CO. Important factors that I need to bear in my mind before I could attempt to do so.
    What information I need to give to the ABAPer or how do I prepare a Functional(or Technical) spec.
    Would highly appreciate if there are any links pertaining to this and also if anyone could share some tips.
    Regards,
    Soujanya.

    http://www.abap.es/Descargas/TAB%20-%20Relacion%20de%20las%20tablas%20por%20modulos.PDF
    you may please search in search engines with
    sap tables .pdf
    sap tables .doc
    You should be able to identify the tables and field names to be populated.
    Technical spec. is more of technical in nature with table and field names, whereas functional spec. is more of explaining the functionality required. A lay man should be able to understanding functionality when they read the FS. Whereas, Technical spec. if purely for technical purposes with lot of table and field names and other technical stuff.
    Check on google for some sample documents.
    Regards,
    Ravi

  • Briefly about internal tables

    briefly about internal tables
    standerd internal tables
    hash internal tables
    sorted internal tables
    index internal tables

    Hi,
    Internal tables : Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs.
    Types of internal tables :
    The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
    Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
    Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional 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. When you define the table, you must specify whether the key is to be UNIQUE or NON-UNIQUE. Standard tables and sorted tables are known generically as index tables.
    Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
    Creating Internal Tables
    You define internal tables first as an abstract data type in the program or ABAP Dictionary, and then as a data object based on that, or they are declared directly as a fully specified data object. When you create an internal table as a data object, you should ensure that only the administration entry which belongs to an internal table is declared statically. The size of table headers for initial tables is currently 8 bytes. This should be heeded whenever internal tables occur as components of complex data objects. Also, empty tables can use up a relatively high amount of storage space as components of tables. The size of the entire storage space required for an internal table is not defined in the declaration – as is the case for data objects of the type string or xstring. Table rows are added to and deleted from the table dynamically at runtime by the various statements for adding and deleting records.
    Structure of internal tables :
    STRUCTURE OF INTERNAL TABLE
    TYPES : BEGIN OF ITAB,
                    PERNR TYPE PERSNO,
                    WERKS TYPE WERKS,
                   END OF ITAB.
    INTERNAL TABLE DECLARATION FOR THE ABOVE STRUCTURE
    DATA : INT_TAB TYPE STANDARD TABLE OF ITAB,
                WA_TAB TYPE ITAB.        "WORK AREA OF THE INTERNAL TABLE
    Thanks,
    Sakthi C
    Rewards if useful *

  • Labview 2013 are closing when I try read table from database.

    Labview 2013 are closing when I try read table from database.
    I don't get error message, Labview just crashes. I'm use Labview x32 and Database Connectivity Toolkit connective on Windows 7 x64. I connect to PostgreSQL with ODBC driver, connection is stable.
    In my database I have many tables, I can read all them without one.
    When I try read bad table I get data and then labview crash. When I restart Labview I don't have any message about error.
    Also I try use LabSQL-1.1a. But it has same result.
    Solved!
    Go to Solution.
    Attachments:
    DBT.png ‏104 KB
    LabSQL.png ‏67 KB

    Try connecting using UDL file. What operation you are doing with database
    You can create the same.. Do this Tools --> Create Data link..
    Then go to http://www.ni.com/pdf/manuals/371525a.pdf link and see page 3-5. It will help
    Kudos are always welcome if you got solution to some extent.
    I need my difficulties because they are necessary to enjoy my success.
    --Ranjeet

  • Question about Update Tables

    Hello Gurus,
    I have a question about "update table" entries. I read somewhere that an entry in update table  is done at the time of the OLTP transaction. Is this correct? If so, does this happen on a V1 update or V2 update? Please clarify. Similarly, an entry in the "extraction queue" (incase you are using "queued delta" will happen on V1 update. I just want to get a clarification on both these methods. Any help in this matter is highly appreciated.
    Thanks,
    Sreekanth

    Hi
    update tables are temporary table that are refreshed by v3 job.update table is like buffer, it gets filled after updation of application table and statistical table through v1 v2 update .  we can bypass this process by delta methods.
    M Kalpana

  • Mail spinning, won't delete, "reading table of contents", etc. help?

    First off, forgive my un-tech-ness.
    I recently went away and before I left I
    set my Mail Prefs to disable "remove
    copy from server" since I would be using
    a different computer and didn't want to
    risk losing any mail. Was able to retrieve my
    mail remotely with no problem. However, when I
    returned home, even though I immediately changed
    the preferences back to remove the copies from the
    server right away, each message left on the server was loaded into my inbox three or four times. Then the fun started - spinning ball, messages like "reading table of contents","copying 48 out of 50" "opening mailbox". I moved the duplicates to the trash and even deleted them from trash,but then I had to force quit so when I opened Mail the
    next time, same problems with hanging up and duplicate
    messages all still there. Oddly (maybe not, I don't know
    enough to know what's odd-) I can receive and send mail with no problem. I have to force quit every time. I tried moving MessageRules.plist to Desktop as suggested in another post, but no luck.
    Thanks for any help anyone out there can offer.

    Not sure, but the mailbox appears to have become corrupt (maybe “overstuffed”, see below).
    Verify/repair the startup disk (not just permissions), as described here:
    The Repair functions of Disk Utility: what's it all about?
    After having fixed all the filesystem issues, if any, and ensuring that there’s enough space available on the startup disk (a few GB, plus the space needed to make a copy of Inbox), try this:
    1. Quit Mail if it’s running.
    2. In the Finder, go to ~/Library/Mail/POP-username@mailserver/.
    3. Locate INBOX.mbox and move it to the Desktop.
    4. Open Mail. A new empty INBOX.mbox will automatically be created within the account folder, and this will allow you to continue using Mail normally while trying to solve the problem.
    Although INBOX.mbox appears to be a file, it’s actually a special kind of folder (a package) that contains several files. Ctrl-click on INBOX.mbox and choose Show Package Contents from the contextual menu to see the files it contains. Of these files, mbox is the most important and is where all your messages are stored. What’s the size of that file? Depending on its size, you may or may not be able to directly import it back into Mail in the next step.
    An Incoming_Mail file may also be present, in which case it might contain messages that Mail couldn’t transfer to mbox. Incoming_Mail is also a standard mbox file like mbox proper, just named differently, and can be imported back into Mail in the same way.
    5. In Mail, do File > Import Mailboxes and follow the instructions to import the INBOX.mbox that’s on the Desktop. I’m not sure what the import options available in Mail 1.x are, but you should choose Other / Standard mbox or something like that, so that Mail looks at the mbox file only (and Incoming_Mail, if present) and ignores the other files in the package.
    If Mail doesn’t let you select INBOX.mbox in step 5 because it’s a package instead of a plain folder, rename INBOX.mbox to just INBOX (i.e. remove the .mbox suffix) so that it becomes a normal folder, and try again. You cannot do this directly in the Finder because removing a suffix by normal means causes the Finder to hide the suffix instead of renaming the file. To remove the suffix from the name, you must do File > Get Info (⌘I) on the file and change the name there.
    Do with the imported mail whatever you wish. You may move the messages anywhere you want and get rid of the imported mailboxes afterwards, but take a look at the following article first:
    Overstuffed mailbox is unexpectedly empty
    If all is well and you don’t miss anything, the files on the Desktop can be deleted, although you may want to keep them for a while, just in case.
    Note: For those not familiarized with the ~/ notation, it refers to the user’s home folder (i.e. /Users/username). Hence, ~/Library is the Library folder within the user’s home folder (i.e. /Users/username/Library).

  • Run Rebuild Index Task daily on database but about 77 tables still highly fragmented over 80% !!!

    Hello everyone
    On our particular database server, we run the Rebuild Index Task (Using classic Maintenance Plan Designer) every night. Running the  script below, I saw that about 77 tables had an avg_fragmentation_in_percentage between 80% and 99% !!
    SELECT OBJECT_NAME(ind.OBJECT_ID) AS TableName,
    ind.name AS IndexName, indexstats.index_type_desc AS IndexType,
    indexstats.avg_fragmentation_in_percent
    FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats
    INNER JOIN sys.indexes ind
    ON ind.object_id = indexstats.object_id
    AND ind.index_id = indexstats.index_id
    WHERE indexstats.avg_fragmentation_in_percent > 30--You can specify the percent as you want
    ORDER BY indexstats.avg_fragmentation_in_percent DESC
    I dont understand why these tables are highly fragmented after a daily index rebuild! Unless the users are doing heavy inserts/updates/deletes during the day.
    Anyone has an idea of the possible causes of these results??
    Thank you all in advance

    Hallo Efyuzegeekgurl,
    this is a normal behaviour when your table is only a small one. The reason for that behaviour is the following:
    The dmv sys.dm_db_index_physical_stats counts each page which is not located at the very next one of the same table as a "fragment". If the first data page is 1700 and the second one is located on 1705 SQL server will count it as a fragment.
    The basic allocation algorithm of Microsoft SQL Server is that new data pages will be created in "mixed extents". An extent is a contigious line of 8 consecutive data pages. This is for historical reasons when storage was expensive and data should
    use as much as possible of allocated storage.
    If a new table will be created the very first 8 pages are not located one after the other but "could" be located on different extents. If your table has only 9 data pages than 8 pages will count as "fragmented" because of their non consecutive
    allocation. After 8 pages have been allocated Microsoft SQL Server will ALWAYS use a full extent for the next 8 pages (and so on!).
    To understand this behaviour use the following example which creates a table with a record length of 8K. The next command will create 10 records (which means 10 data pages).
    CREATE TABLE dbo.foo
    Id INT NOT NULL IDENTITY (1, 1),
    c1 CHAR(8000) NOT NULL DEFAULT ('filler')
    GO
    SET NOCOUNT ON;
    GO
    INSERT INTO dbo.foo DEFAULT VALUES
    GO 10
    When you check the page allocation you'll find the first 8 data pages not in a consecutive row but "scrambled" into different pages:
    SELECT database_id,
    index_id,
    partition_id,
    allocation_unit_type_desc,
    extent_page_id,
    allocated_page_page_id,
    is_mixed_page_allocation,
    page_type_desc
    FROM sys.dm_db_database_page_allocations
    DB_ID(),
    OBJECT_ID('dbo.foo', 'U'),
    0,
    NULL,
    'DETAILED'
    ) AS DDDPA
    WHERE
    DDDPA.is_allocated = 1
    ORDER BY
    DDDPA.is_iam_page DESC,
    DDDPA.page_level DESC;
    GO
    You will see that the first 8 pages are located in a MIXED extent. Although the pages are in a consecutive order in the extent 221112 it is not guaranteed!
    You can see from the very first three records that they are not in a consecutive row stored.
    Now the fragmentation of the data seems to be quite high because we have 4 breaks in the rows. If we compare this value to the "fragmentation in sys.dm_db_index_physical_stats we will see at least the same result:
    SELECT index_type_desc,
    alloc_unit_type_desc,
    DDIPS.avg_fragmentation_in_percent,
    DDIPS.fragment_count,
    DDIPS.page_count,
    avg_page_space_used_in_percent
    FROM sys.dm_db_index_physical_stats
    DB_ID(),
    OBJECT_ID('dbo.foo', 'U'),
    NULL,
    NULL,
    'DETAILED'
    ) AS DDIPS;
    So - just from my point of view - don't count only to the fragmentation in percent because if the table is to small it will ALWAYS be over 30%. Take more into account the density of the pages and - as all others have mentioned - the number of pages of the
    index.
    I would consider indexes with more or equal to 1.000 pages.
    Another tip: Forget about the f... maintenance plans. These "plans" are not worth the time and money because you cannot control it in a more precise way. Have a look to the solution of Ola Hallengren and implement his solution - a great master
    piece of index maintenance:
    http://ola.hallengren.com
    All the best to the community :)
    MCM - SQL Server 2008
    MCSE - SQL Server 2012
    db Berater GmbH
    SQL Server Blog (german only)

  • Sy-tabix in relation to LOOP AT and READ TABLE

    Hi All,
    As per SAP documentation,
    1) While looping through an internal table (LOOP AT), sy-tabix contains the index number of current row(for standard and sorted tables)
    2)When successfully reading from an internal table(READ TABLE), sy-tabix is set to the index of the result row.
    But what happens when READ TABLE is used while looping through another internal table?
    i.e. Loop at TAB1...
    write sy-tabix.
    READ TABLE TAB2...
    write sy-tabix.
    endloop.
    If we are looping through 1st row of TAB1 and the result of read statement is found in 3rd row of TAB2, I expected that sy-tabix before READ would be 1 and after the READ be 3.
    But, I found that sy-tabix remains unchanged at 1. Can someone expalin why?
    Thanks,
    Jagan

    Hi
    If after reading the table TAB2 the system variable SY-TABIX has still the previous value, that menas the READ TABLE fails or it was read the first record of TAB2.
    After READ TABLE TAB2 try to check the SY-SUBRC:
    LOOP AT TAB1.
       WRITE: / 'TAB1 index:', SY-TABIX.
       READ TABLE TAB2 .........
       IF SY-SUBRC = 0.
         WRITE: 'TAB2 index:', SY-TABIX.
    Try this:
    DATA: BEGIN OF ITAB OCCURS 0,
            FIELD1,
          END   OF ITAB.
    DATA: BEGIN OF ITAB2 OCCURS 0,
            FIELD1,
          END   OF ITAB2.
    DATA: INDEX TYPE I.
    DO 10 TIMES.
      APPEND ITAB.
    ENDDO.
    DO 10 TIMES.
      APPEND ITAB2.
    ENDDO.
    LOOP AT ITAB.
      WRITE: / 'ITAB:', SY-TABIX.
      INDEX = SY-TABIX + 2.
      READ TABLE ITAB2 INDEX INDEX.
      IF SY-SUBRC = 0.
        WRITE:  'ITAB2:', SY-TABIX.
      ENDIF.
    ENDLOOP.
    Max

Maybe you are looking for