View source for Table E and non-FILEORG X'100' files (File architecture)

<span class="pageSubtitle">Holds Large Object data (BLOBs and CLOBs)</span> 
 
Storage and manipulation of [[Data_maintenance#Large Object storage|Large Objects (LOBs)]] differs greatly depending on whether <var>FILEORG</var> X'100' is set for the file. This page discusses working with files where <var>FILEORG</var> X'100' is ''not'' set; for a parallel discussion of working with LOBs in files where FILEORG X'100' ''is'' set, see [[Table E and FILEORG X'100' files (File architecture)]]. For a summary of the differences between working with LOB data in files where <var>FILEORG</var> X'100' is set and files where it is not, see [[Table E (File architecture)]]. 

<var class="product">Model&nbsp;204</var> stores Large Objects as consecutive chunks of Table E pages. When Large Objects are created and deleted frequently, gaps can occur between objects that may not be reused due to their small size.

When the <var>FILEORG</var> X'100' bit is not set on a file, you enable Large Object storage by: 
<ol>
<li>Reorganizing/[[CREATE command: File|creating]] a file with <var>[[ESIZE parameter|ESIZE]]</var> parameter value greater than 0.

<li>[[DEFINE FIELD command|Defining one or more fields]] with an [[Field design#BLOB.2C CLOB.2C and MINLOBE attributes|attribute of CLOB or BLOB]] (the file must have a non-zero <var>ESIZE</var> value for the latter to occur). 
</ol>

Table E storage of LOB data is available as of Model 204 V7.1. 

==Summary==
Regarding the storage and manipulation of Large Objects (LOBs): 
<ul>
<li>Table E storage of files that are <i>not</i> defined with the <var>[[FILEORG parameter|FILEORG]]</var> X'100' bit is a reasonable choice for static stores of Large Objects (such as scanned forms). </li>

<li>If you expect that there will be large numbers of adds, changes, and deletes, however, strongly consider [[Table E and FILEORG X'100' files (File architecture)|using FILEORG X'100' files]]. </li>
</ul>

==Bitmaps to track space availability==
In Table E, in addition to the pages used to store the Large Object Data, there are bitmap pages which track the page use. For every 49152 pages of Table E defined, there will be one bitmap page.

The boundaries of these sets of records are a consideration in the execution of the <var>[[COMPACTE command|COMPACTE]]</var> command, because the compactor processes one of these sets at a time, and LOBs stored on pages that span a bitmap boundary do not participate in the compaction.

==Storing Large Objects==
When a field is defined as a large object (LOB) (using the attributes <var>[[Field design#BLOB attribute|BLOB]]</var> or <var>[[Field design#CLOB attribute|CLOB]]</var>), a pointer is stored in the record (in Tables B or X) and the LOB is stored in Table E. 

===Pointer in the record===
When you store a Large Object value in Table E, a Large Object descriptor is stored in Table B (or Table X depending on where the field is being added). The descriptor contains the length, reserve, and a pointer to the Large Object data in the Table E page and is 27 bytes long (or 30 bytes long if the field is not preallocated).

===Large Object header===
<p>
Every large object stored in Table E starts with a Large Object header, which is used to make the [[COMPACTE command|Table E compaction]] work better. The Large Object header contains a field for the Table B record number that points to the large object&#x2014;thus the field is a backward pointer to the Table B record.</p>

<p>Implementing a Large Object header requires file reorganization if the file was created earlier than V7.1. Only V7.1 or later files are eligible for <var>COMPACTE</var> processing. No application changes are required.</p>

<p class="note">'''Note:''' Files created in V7.1 with Table E size greater than zero are not backward compatible and cannot be opened in earlier releases.</p>

<p>The large object header has the following 4-byte entries:</p>
<ul>
<li>Table B record number</li>
<li>Large object length in pages, including reserved pages</li>
<li>Field attribute
<p>The field attribute facilitates the Table B record search to find a field with the object descriptor.</p>
</li>
<li>Five reserved fullwords </li>
</ul>

<p>So, the first 6132 bytes of a Large Object are on the first Table E page, while later pages will fit 6144 bytes. If you plan on storing a large number of relatively small LOBs, take this size differential into account when sizing Table E.</p>

===Table E space utilization===
Each instance of a Large Object field occupies an integral number of Table E pages, where each page can hold up to 6144 bytes of data (the first page only 6132 due to the header).
<ul>
<li>A Large Object field with a null value (or 0 bytes of data) occupies no Table E pages.

<li>Large Object field data from 1 to 6132 bytes occupies one Table E page. If the data is from 1 to 6131 bytes, the page is not completely filled, so the remainder of the page is unused.

<li>Large Object data of 6133 bytes requires two Table E pages, and LOB data of 12277 bytes will take three pages (6132 + 6144 + 1).
</ul>

===Storing a Large Object===
<p>
The pages used to store a Large Object value are always contiguous in Table E. If you specify the <var>RESERVE</var> option when the data is stored (and you must if you wish the object to expand in size after its initial store), then enough contiguous pages are allocated to hold the full <var>RESERVE</var> length, even if the actual size of the data initially stored is less than that.</p>

<p>If possible, when space to store Large Object data is required from Table E, then the space is allocated from the pages past <var>EHIGHPG</var>&#x2014;even if there are free pages in Table E before the <var>EHIGHPG</var> point. In other words, data in Table E is initially stored in entry order. Eventually, when there is insufficient space left at the end of Table E, then space is allocated from the unused pages
in Table E. Unused pages are a result of deleting Large Object data.</p>

<p>Generally speaking, the cost of finding free space in Table E is very low during the initial phase, when <var>EHIGHPG</var> is still increasing, but more expensive later, particularly when Table E free pages are fragmented: for example, if the Large
Object data stored in the file show a wide variation in size.</p>

<p>If the Large Object data stored in your database are volatile because of a high number of deletions and additions, Rocket Software recommends that you use <var>[[FILEORG parameter|FILEORG]]</var> X'100' files.</p>

==Parameters and commands related to the use of Table E==

<table>
<tr class="head">
<th>Name</th>
<th>Description</th><tr>
 
<tr><td>[[COMPACTE command]] </td>
<td>Defragment the contents of Table E. </td></tr>
 
<tr><td>[[EHIGHPG parameter]] </td>
<td>The highest active Table E page. (The first page in Table E is page zero.) </td></tr>
 
<tr><td>[[EPGSUSED parameter]] </td>
<td>The number of Table E pages currently in use. </td></tr>
 
<tr><td>[[ESIZE parameter]] </td>
<td>The number of pages in Table E. </td></tr>
 
<tr><td>[[FILEORG parameter]] </td>
<td>The file organization. </td></tr>
</table>


[[Category:File architecture]]