In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
  
Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel

Index Record Layouts

!INDEXING

The !INDEXING file has a simple layout. Each record represents a group of pending transactions waiting to be applied to indexed files. They are stored in such a way that chronological accuracy is ensured (that is, if two changes are made to the same item, the changes will be applied to the index files in the order they were applied to the data file).

Note though that when a relationally indexed record is written to file, a transaction record is generated in the !INDEXING file regardless of whether the related record was updated. This is simply explained by the fact that on a network a user might have attempted a change before you and been unsuccessful. Their change would be written to the !INDEXING file to await processing. When the transaction record was processed, their change would be applied to the related file, effectively undoing your more recent change. If your update had not generated a transaction record this situation would not be rectified.

The only "special" record on the !INDEXING file is record 0, all other records are homogeneous. In record 0 field 1, the record key of the most recent transaction record is stored. When an index update is attempted, record 0 is read and the transactions are added to it. If this forces the size of record 0 to exceed 1K, the latest transaction record (pointed to in field 1) is read and the index transactions are added to the record. Again if the size of the record exceeds 1K, the record is split and the next transaction record created (and record 0 updated accordingly) and a pointer to the next record put into field one of the current record.

The transaction records have the following structure

     < 1 >     Pointer to next transaction record
     < 2>      File details in format FILE*ACCOUNT*VOLUME_NAME
     < 3>      Number of transactions following for the file mentioned in
               field 2. Note that as each of the following transactions is
               four fields long, this can be used to calculate offsets if
               the file to be updated is not available.
     < 4 >     Name of field to update
     < 5 >     Item ID being indexed
     < 6 >     Old Value
     < 7 >     New Value

Fields 2 through 7 repeat until the record reaches approximately 1K.

!filename transaction records 0, 1 2 and other integers When FILE.DISTRIBUTOR transfers records from the !INDEXING file it does so by transferring ALL index transactions for a file (regardless of field) into transaction records in the !filename file having a sequential key. As transaction records are added, they are created in a similar way to that in !INDEXING. The records have a slightly different structure though, as follows;

     < 1 >     Pointer to next transaction record
     < 2>      Name of field to update
     < 3>      Item ID being indexed
     < 4 >     Old Value
     < 5>      New Value

Fields 2 through 5 repeat until the record reaches approximately 1K.

Index_Name*, Index_Name*1 , ...2 ...3 and other integers When F.DISTRIBUTOR transfers records from the process described above it separates out the index transactions into their respective fields and builds transaction records accordingly, with each index transaction record having a key of field_name*integer. The record holding the base information is not field_name*0 though, it is field_name*. As transaction records are added, they are created in a similar way to that in !INDEXING. The records have a slightly different structure though, as follows;

     < 1 >     Pointer to next transaction record
     < 2 >     Item ID being indexed
     < 3 >     Old Value
     < 4 >     New Value
(Volume 2, Issue 9, Page 7)
Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel