Today we will talk a bit about packing tables and why that sometimes is necessary.
A Native MapInfo table is basically a small database in itself. In the DAT file, the attributes for the data are stored in a binary form making access very efficient.
A few decisions have been made to make MapInfo Pro work efficiently with these data files. One decision affects how deleted records are handled. When you delete a record, the data for that record is not removed from the DAT file as that would require additional work to rewrite the content of the TAB file in a new order without the deleted record.
Instead, a small flag for the record is set indicating that that specific record has been deleted. The best way to visualize this is to open the table in a browser. Any deleted records will be shown as a small grey line as you can see below.
A table with deleted records works fine in most situations in MapInfo Pro. There are however a few things that will be affected by deleted records.
The row count for a table also counts the deleted records and will so not tell the entire story of your table.
A table also has a spatial extent. This will also contain potentially deleted records. This is of course only a problem if you delete records at the bounds of the data. You can see the effect of this when you use View Entire Layer and zoom to the extent of the layer in a map window. This extent can in some cases be too big.
Finally, you may also run into issues when joining a table with deleted records to another table. This issue may arise if you join them using a SQL statement but also if you try to join the tables through Update Column or potentially through Join when creating a thematic map. You will get an error if there is a problem like this.
Packing your table on the other side is quite easy.
From the Table dropdown under Maintenance on the Table tab, select Pack.
In the Pack dialog, you can now select the table or tables to pack, and the Pack Mode too.
The Simple mode simply packs the table. This will result in the table being removed from any windows and queries based on the table will also get closed.
Alternatively, you can use the Advanced mode. This will save your current session to a workspace, perform the pack operation, and then reopen that saved workspace again.
Personally, I prefer using the Simple mode and making sure everything I want to maintain is saved to a workspace before packing the table. Afterward, I can then close all and reopen the workspace I saved.
Keep in mind no matter what process you use, there are still a few things that can't be maintained in a workspace. That could be queries that you have made using some of the manual selection tools.
When a table is packed, the content of the table is basically saved into a new table and by doing so only the not-deleted records are kept and the spatial data extent is recalculated too.
And as a final comment, I also want to highlight that it's not all tables that need packing or can be packed. The pack dialog will only list the tables that you can pack.
Notice how the Pack Table list doesn't contain WFS and Tile Server tables as examples of tables that can't be packed.
Any image or raster table can't be packed. In fact, it's only Native and NativeX MapInfo Tables that require packing.
Have you packed your tables lately?
Hi PeterThis caught my eye:Instead, a small flag for the record is set indicating that that specific record has been deleted.Is there a way to change that deletion flag in order to "undelete" records and geometries?Thanks for your time
Instead, a small flag for the record is set indicating that that specific record has been deleted.
------------------------------Peter Horsbøll MøllerPrincipal Presales Consultant | Distinguished EngineerPrecisely | Trust in Data------------------------------
Hi,There is no official way to undelete records. If you are really in troubles and need to get a record back, there are actually three places that need to be edited:1) In the DAT file there is this flag, which Peter mentions. DAT is in many ways the same as DBF, so you can see the format here: https://en.wikipedia.org/wiki/.dbf2) If there is also a MAP/ID part in the TAB file, then you also need to recreate the ID file, since the pointer within the ID file to the geography in the MAP file, is also set 0 and it can not be uncleared. Rather it is possible to create the whole ID file again from the content in the MAP file. I wrote such an application long time ago and it may still work if your MAP file has the original blocksize of 512 and it is a NATIVE table. Newer versions of MapInfo uses larger block sizes by default.3) There is actually also a flag for each record in the MAP file, which needs to be cleared. How we are talking really low-level stuff...If new records has been added, after records have been deleted, it may not work at all. That experiment I have never run :-)
Thank you for your reply.I was just curious, but good to know there might be an alternative just in case.