4th Dimension™ is a Relational Database Management System (RDBMS) published by the ACI SA company.

4th Dimension™ creates 2 distinct files:

• The first one contains the data capture users and an index of fields.
• the other containing the database structure. That is to say, all the objects created by the developer. .

The maintenance of the database is largely simplified since the files containing programming and accessed data are completely distinct.

Why Rescue for 4D Data??

Unfortunately, and all too often, a problem arises (a bug, bombs, power source interruption...) which can make a database unusable:

• the structure file : The main cause is bad recording in 4^th Dimension's internal resources. This problem can generate strange occurences in the database; in the worst case scenario, a warning message will be displayed when you open the structure : "attempt to read beyond the end of file." This may result in a day (or more) of lost work. The validity of your data is entirely dependent upon good structure. A damaged structure can damage the data. This is why we created Rescue For 4D.
  
  
• the data file : this principally generates problems with the index. The first symptom may be the presence of forbidden characters in the field content. These forbidden characters can generate erroneous search results, make it impossible to store records (modifications), or, in the worst case, a bomb!
  
  It should be noted that 4D Util is then... useless!
  
  To avoid these problems with your database, we created Rescue for 4D Data.

---

Structure of 4D Database

 

 

The graph above shows, in summary, the structure of a 4D database.

DSH	Data Segment Header.Header of the data file. It contains principal information about the database as well as links pointing towards other objects.
FIT	File Information Tables. Contains information on the tables and their organization.
FI	Contains the detail of each table (record number, position, table delete, etc...).
PRA	Primary Record Address. Primary address records. Points to the SRA. A PRA can point to 4096 SRA.
SRA	Secondary Record Address. Secondary record address. Point to the records. A SRA can point towards 1024 records in v.5 or 512 in v.6.
IHT	Index Headers Tables. Contains information on the indices and their organization.
II	Index Information. Contains the details of each Index (index number, position, etc...).
PIAT	Primary Index Address Tables. Primary index addresses. Points to the SIAT. A PIAT can point to 4096 SIAT.
SIAT	Secondary Index Address Tables. Secondary index addresses. Points to the pages of index. A SIAT can point towards 4096 Pages of an index.
IP	Index Page. The indices are contained and classified in these pages.

 

 

Structure of a Record

 

 

 

Record Header	This zone contains information on the record (checksum, record number, size, etc...).
Field Information	Contains the position and the type of each field --- with the exception of the variable size fields 'Text, Picture, Blob, and SubField'.
Fixed Field Data	Information on fixed size data fields (alpha, num, integer, etc...).
SubField Data	Information concerning all the fields of a substructure, in the form of "sub record." This even includes all the fields of the substructure of the substructure of...
Variable Field Data	Variable size data fields like 'Text, Pictures, and Blobs'. However, there is no pointer to these fields. And because of this, 4D is forced to traverse them all before arriving at the one you choose.

 

Comment on the Substructures :

 

For the Developer :

 

• 4D cannot build semi-automatic states on the substructures.
• Nor can it build graphs on the substructures without passing by a table.
• Import/Export of substructures inevitably pass by programming.

Once created, the substructure becomes indestructible.

It is impossible to make sub-selections of substructures.

It is impossible to display a list of substructures greater than 32,000 lines: this is the limit dictated by the 4D List Manager.

For 4D :

The substructures are fields in the fields. Thus, if a field is damaged, you lose all the sub-fields.

As there is no sub-field pointer, 4D is obliged to parse all the sub-fields before arriving at the one you wish to view.

If one of your sub-fields is damaged, the whole field will be unreadable.

The variable size fields follow (in order or progression) the sub-fields. In order to reach the variable size fields, 4D must first read all the sub-fields.

When performing a Find or a Sort, 4D cannot read only a part of a field.
This defect obliges 4D to load in memory the whole field and, thus, its sub-fields. This requires time and, of course, memory.
If there is not enough memory available in the cache, 4D flushes the cache. We will let you imagine the time wasted to reach a simple field...

The modification of only one field, in this kind of record, initially causes a reorganization of memory, then the disk, then ALL of the record.

When one is in a 4D list, and one displays a variable size field (standard Text, for example), the display is CONSIDERABLY slowed by the presence of sub-fields.

If one multiplies the number of PIAT(512) * SIAT(512) * IP(64) = 16.777.216 index on a field. That is to say, the maximum number of fields per file.
However, a field can contain of 0 to X sub-fields. Let us imagine a database of 1,2 million records, each containing 20 sub-fields: this yeilds 24 million sub-fields. If a field of the sub-field is indexed, 4D WILL NOT BE ABLE TO CREATE the INDEX.

These remarks do not reflect only ACI :

• Did you not think of the sub-fields as a truly viable solution????
  
• Did you not think that, one day, there would be such large databases; -))
• Did you not make the sub-files to last over time;-)))))))