Re: Perform Data Ordering.

In article <1992Oct8.224918.20188@sequent.com>, kevinc@sequent.com (Kevin Closson) writes: |> In article <9638@emory.mathcs.emory.edu> maint72@saad-emh1.ARMY.MIL (Michael Gordon) writes: |> > 1. Open the TABLE and check for INDEXED fieldnames, the |> > fieldnames for last_name and first_name must be indexed. |> This technique should only work on static tables. Should a row of |> "Johnson" be deleted and then a row of "Smith" be inserted, the ordering |> will be broken. No, that would be a problem if you were relying on the physical order of the records in the table, but that's not what was suggested: if you were relying on the physical order, it wouldn't matter if there was an index. I don't know the internals, so I don't know how reliable the suggestion is, but the idea is this: Experience indicates that perform _tends_ to use an index if one is available, rather than just reading the table directly (probably this allows it to skip deleted rows efficiently?). If there's more than one index, I don't know how it decides which one to use. But if there's only one index, it tends to scan rows via that index, and since the B-tree (?) index is ordered by the key field, perform returns them in that order. So Michael Gordon's suggestion tends to work, although it's not guarranteed as far as I know. -- Harry Bochner bochner@das.harvard.edu