OSGeo
Don't call all records deleted if record count is not set
Some DBF files are written without a record count (because, say the SHP file or SHX file already give a record count. In that case, checking the shape index being > number of records always returns deleted, which is not correct.
So, doing some testing with our regression files... I loaded up a the point file, which looks like this:
CREATE TABLE "point" (gid serial);
ALTER TABLE "point" ADD PRIMARY KEY (gid);
SELECT AddGeometryColumn('','point','geom','0','POINT',2);
INSERT INTO "point" (geom) VALUES ('01010000000000000000000000000000000000F03F');
INSERT INTO "point" (geom) VALUES ('01010000000000000000002240000000000000F0BF');
INSERT INTO "point" (geom) VALUES ('01010000000000000000002240000000000000F0BF');
So, a table with only a point column. Then dumped it, both with ogr2ogr and with pgsql2shp. The DBF file from ogr2ogr looks like this
Sparrow:/tmp pramsey$ hexdump foo.dbf
0000000 03 77 0c 03 03 00 00 00 41 00 0c 00 00 00 00 00
0000010 00 00 00 00 00 00 00 00 00 00 00 00 00 57 00 00
0000020 46 49 44 00 00 00 00 00 00 00 00 4e 00 00 00 00
0000030 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000040 0d 20 20 20 20 20 20 20 20 20 20 20 30 20 20 20
0000050 20 20 20 20 20 20 20 20 31 20 20 20 20 20 20 20
0000060 20 20 20 20 32 1a
It looks like ogr2ogr adds in a FID column during the dump, so ogrinfo returns this:
OGRFeature(foo):0
FID (Integer64) = 0
POINT (0 1)
The DBF file from pgsql2shp on the other hand:
0000000 03 5f 07 1a 00 00 00 00 21 00 01 00 00 00 00 00
0000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000020 0d
So, this is generated using shapelib, naturally, and it's got the record count all zeroed out. I'm guessing that this is a result of the dumper not trying to write any tuples because there's not any fields. Or maybe writing tuples but with no fields added. Have to confirm still.
Implication being, we've been generating DBF files with pgsql2shp that have a zero record count in the case of geometry-only tables, and doing so for 18 years... so there are definitely some in the wild. Hm.
so there are definitely some in the wild.
OK, so if we want to support such files in shapelib (and then in GDAL), I would suggest a different approach that will be less invasive than patching all sites where we look for num_records. If the num_records header is read to be 0 at file opening, then compute its value from the file size and record size.
The size of the DBF file seems invariant to the number of rows...
Looking into the dumper, it only calls DBFWriteAttributeDirectly when the number of non-geometry fields is non-zero. So we go through the dumping process never writing anything to the DBF except for the header when we open the file. I wonder what the correct workflow is for the DBF in the case where it has no fields?
The size of the DBF file seems invariant to the number of rows...
I don't get this. Normally file_size (roughly) = fixed_header_size + number_of_fields * field_description_size + number_of_rows * record_size
I wonder what the correct workflow is for the DBF in the case where it has no fields?
In that case, OGR creates a dummy "FID" field so that there's at least one field