|
<< Click to Display Table of Contents >> Table packing, security issues |
![]() ![]()
|
Packing tables first of all may reduce disk size of the tables, as adding and deleting records for the sake of speed is not always optimal concerning use of space.
This is the matter for most database management systems, but especially for dBASE, FoxPro and other databases using the .dbf table files, not continuously packing tables may be a serious security issue.
Table packing in PdxEditor is done via the Table menu. The table to be packed must be in exclusive mode (not concurrently accessed by other users).
In common for dBASE, xBase application and FoxPro deleting records in reality does remove the "deleted" records but just mark them as trash.
Only after packing .dbf tables the deletion marked records are removed from the data table.
You may try creating a simple single field .dbf table by the SQL statement:
CREATE TABLE dBaseSimple
(FieldName1 VARCHAR(30));
This empty table would look like this opened in a simple text editor in binary mode:

You may enter some secret information into the first record, storing it, and successively delete that record.

After deleting the secret information by deleting the record, re-opening the table file in the text editor will reveal your secret code.
Please note the asterisk "deletion marker" preceding the "deleted" record which is the .dbf format's standard way of trash marking deletions to be removed only later by separate table packing.

Last it has to be noted, that some dBASE applications (not PdxEditor) actually do offer regenerating deleted records in dBASE tables.
__________________________