|
<< Click to Display Table of Contents >> Navigation: Apollo API (Apollo Engine) > VariField Data Storage |
Apollo adds three new field types to the group of xBase field types. The previous section discussed Enhanced Date and Enhanced Numeric fields. The third field is an extremely flexible, variable-length and indexable field called of type V, for VariField. This section will explain exactly what VariFields are, and why you might want to incorporate them into your table structures.
VariFields allow you to store a portion of any character data in the .DBF field itself, with any additional amount being automatically stored in the MEMO file. This substantially reduces the amount of disk space required to store the data. Plus, you can index on the portion that remains in the .DBF! What you get in functionality is sort of a cross between using a Character field and a Memo field. You get the best features of both.
Note: In addition to the above description of storing character data in VariFields, you may store other types of data into VariFields as well. For instance, you can store an xBase logical (T/F), in a VariField. You can even store a Logical for record one, and something else, a date for instance, in record two. Be aware that if you do this, (store different types in the same field over different records) data-aware components in your application will lose cohesion. They will not work properly at all. For this reason, it is generally not advisable to store your data this way.
A 6 byte pointer is maintained at the end of the 'V' field entry within the DBF file. When you define the field width for a new table you need to keep this in mind. For example, if you create your table with a 'V' field of 16 bytes, the first 10 bytes are considered 'significant'. If you index on this field, the key will be 10-characters wide. The last six bytes are for the pointer information. The rest of your data will be stored away in the memo file.
For example, if you store 30 characters of text into this field, the first 10 characters are stored within the DBF field, with the remaining 20 characters being automatically stored in the memo file. No special functions are required to store or retrieve the field data in this manner. If, however, you store only 14 bytes into your 16 byte 'V' field, nothing will be written to the memo file. Nothing needs to. In this case, the VariField system is smart enough to see that, had the four byte pointer to the memo not been in the way, the whole entry would fit in the .DBF field alone. So, it gives up the four bytes to your data. The last two bytes, however, are always reserved to store the length of the text in the 'V' field.
Depending on the structure and content of your data tables, it is possible to cut the size of your data files in half using VariFields and the compressed Numeric and Date fields discussed in the previous section. With VariFields, you can also reduce your index size, since indexes will only be created on the significant (e.g. defined minimum length) portion declared in the table structure. If you can significantly reduce the overall size of your data files as well as your index files, you can dramatically improve data processing speeds, especially on networks.
As with the enhanced date and numeric type fields, if you do not want to use these features, you don’t need to worry about accounting for them. Your code will work as is. To take advantage of VariFields, you need to learn how to create them and what to expect from them when you read and write data to those field types. You create VariFields via the additional field declarations available to you in the sx_CreateField function.