4D v12 includes a new command called Get table fragmentation. This command reports the percentarge of records that are not located contiguosly in the data file for the given table.

Typically if records are not contiguously located a database compact will resolve the issue. However in certain situations Get table fragmentation may continue to return a non-zero value even for compacted tables. To understand how this can happen it is important to understand how 4D tracks space in the data file.

When 4D needs to locate free space in the data file, for example, it does not "scan" the whole data file. That would be very inneficient. Instead, for every 2 MiB of data file content, 4D creates a 2 KiB "bit table". Each bit in the bit table corresponds to a 128 KiB block of the data file. If a bit in the bit table is 1, it means that block of the data file is occupied. If the bit is 0, that block is free.

These bit tables are created "as needed", i.e. they are not located in one particular place. So, for example, say a table contains records that are 1 MiB in size. This means that, for every 2 records, 4D needs to allocate 1 bit table. A database compact of this table will result in data file content like this:

[bittable1][record1][record2][bittable2][record3][record4][bittable3][record5][record6][etc]

Note: In fact, the implementation is not exactly this simple because each bit table also needs to be allocated like any other data file object and so its space must be tracked in another bit table. But because it is quite small (2 KB), we can ignore that for this example.

Get table fragmentation returns the percentage of records that are not stored contiguously. If there are bit tables between the records, the level of fragmentation reported will increase. So in the example above Get table fragmentation will return near 50%.

This is not a problem per se, it just reflects the reality of objects allocated in the data file. The fact is, because those objects are so large, they will be innefficent to access no matter what (mutliple blocks of data file will need to be loaded) so the fact that they table is considered fragmented is a non-issue in this case.

Note:

1 Kib = 1,024 bytes
1 MiB = 1,048,576 bytes